Systemd Supremo Proposes Tightening up Linux Boot Process (theregister.com) 123
Lennart Poettering's latest blog post proposes moving the Linux boot process into a "Brave New Trusted Boot World" of cryptographically signed Unified Kernel Images. From a report: Agent Poettering offers a mechanism for tightening up the security of the system startup process on Linux machines, using TPM 2.0 hardware. In brief, what he sees as the problem is that on hardware with Secure Boot enabled, while the boot process up to and including the kernel is signed, the next step, loading the initrd, is not. That's what he wants to fix.
what about kmods? (Score:3)
what about kmods?
Re: (Score:3)
You can either embed a certificate in the kernel during build, or the kernel will pull MOK keys from the shim, and allow those to be used for validation.
As long as I can run without (Score:2)
Re: (Score:3)
And this is solving which problem exactly?
Well, apart from addressing Poettering's desire to have everythingd do pretty much everything.
Re: (Score:3)
Don't be such a downer. Nothing is so wrong with systemd that more systemd can't fix.
It has begun (Score:1)
Popcorn is ready! A high profile Linux dev advocating TPM?
Re:It has begun (Score:4, Insightful)
Poettering is not a linux dev.
Re: (Score:3, Interesting)
He does seem rather intent on bringing windows' problems to linux.
And so far, he's succeeding swimmingly.
Re: (Score:3)
Re: It has begun (Score:1)
I've felt that way about Layer 7 from time to time.
Re:It has begun (Score:5, Interesting)
Now that Microsoft is paying him, I guess we are in the extinguish phase. Or more likely the start of absorption phase.
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
It started with secure boot, now we have this. Forcing the use of TPM 2 ? Not for me, and my system does not even have TPM 2. Glad the OpenBSD folks are sane when it comes to Operating Systems.
Re:It has begun (Score:4, Insightful)
I guess we are in the extinguish phase
No we're not, not if you give this a modicum of thought. There's many reasons why any comparison to EEE and modern Microsoft vs Linux is incredibly silly.
a) MS doesn't have the market share to dictate any Linux standard.
b) MS makes actual money off Linux (a good 50% of their biggest cash cow: Azure, runs on Linux).
c) MS leadership doesn't have the skills to execute EEE properly (too short sighted).
d) MS gains nothing by extinguishing Linux. Especially considering what little market share exists is irrelevant to them.
Re:It has begun (Score:5, Insightful)
a) MS doesn't have the market share to dictate any Linux standard.
Microsoft has the market share on OS preinstallations to dictate what Secure Boot certificates are enrolled out of the box on prebuilt PCs.
Re: (Score:3)
Microsoft has the market share on OS preinstallations to dictate what Secure Boot certificates are enrolled out of the box on prebuilt PCs.
And? Secure Boot is something within user control. In fact if you block the ability to install custom certificates you lose MS's "Designed for Windows" certification (or whatever they call it these days since they change the name with every other release).
Honestly the Secure Boot fearmongering is getting tiring. A decade of nothing. You guys are starting to look like those crazy people at the street corner holding signs saying "The end is neigh".
Re: (Score:2)
How easy is it for a less-technical user who is trying a non-Windows operating system for the first time to add a custom Secure Boot certificate? How much does the procedure differ from one BIOS publisher to another?
Re: (Score:2)
a) MS doesn't have the market share to dictate any Linux standard.
I suspect you need to define what market share means in your words. Microsoft has close to 100% market share except for server operating systems... in which they still dominate.
b) MS makes actual money off Linux (a good 50% of their biggest cash cow: Azure, runs on Linux).
So what? They do not control Linux; therefore, they want to kill it.
c) MS leadership doesn't have the skills to execute EEE properly (too short sighted).
During the reign of Gates and Ballmer, sure. But now?
d) MS gains nothing by extinguishing Linux. Especially considering what little market share exists is irrelevant to them.
There is that market share term again; however, in this case, it is irrelevant. Microsoft gains control of what is available to the general public if Linux is extinguished.
Your thought process is exactly what a Mic
Re: (Score:2)
I suspect you need to define what market share means in your words. Microsoft has close to 100% market share except for server operating systems... in which they still dominate.
Indeed it does, but given that Linux is not existent outside of servers, what's your point regarding EEE? Do you generally go and defeat non-existent competitors?
So what? They do not control Linux; therefore, they want to kill it.
Probably the single dumbest comment ever made based on corporate strategy. Again not only is there no reason for MS to kill Linux, they make a significant profit thanks to its existence which is why they promote Linux both within windows and on their cloud platform.
During the reign of Gates and Ballmer, sure. But now?
Are you making my point for me? You agree that there's difference in leadership betw
Re: (Score:2)
Then why is he talking about Linux?
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
High-profile wannabee with kernel-envy maybe...
Re: (Score:3)
Re: (Score:2)
I would welcome that. Then I could simply ignore his crap instead of having to work around it.
Re: It has begun (Score:1)
Said everyone who ever wanted to push their own patch somewhere......
Re: (Score:2)
You need to learn about implications. Here is a hint, they go in one direction but not the other. That concept may be out of mental reach for you, admittedly.
Re:It has begun (Score:4, Informative)
Re: (Score:2)
"Almost like he's talking to someone behaving like a child."
FTFY
Re: (Score:2)
"Also linux is a single machine single user model "
Last time I checked Linux was stilll multi-user and could be put into a cluster using various types of software.
Fuck off Lennart... (Score:5, Insightful)
Even if it wasn't for the PulseAudio fiasco that still leaves a bad taste in Linux users' mouths, or the way systemd was rammed through - you're now at Microsoft and therefore have NO BUSINESS recommending architecture changes to the OS that I'm sure your corporate masters would still love to Embrace, Extend, and Extinguish.
Kindly restrict your fuckery to Windows and other Microsoft products - that's a software ecosystem that already expects the kind of shit you get up to.
Re: (Score:1)
you're now at Microsoft and therefore have NO BUSINESS recommending architecture changes to the OS that I'm sure your corporate masters would still love to Embrace, Extend, and Extinguish.
OEM motherboards come with two public keys installed. Microsofts and that specific OEMs.
Microsoft is the only holder of the global root signing keys for secure boot.
Even one OEM can't sign a boot loader that works on another OEMs boards.
Unfortunately for the rest of the world, Lennart working at Microsoft and pushing a locked down boot process really is their business.
Re:Fuck off Lennart... (Score:5, Informative)
While what you describe is bad, Lennart's proposal would be different, as the keying material would be unique per device. He'd be leveraging the PCRs. For example, a Linux encrypted disk may have key sealed to PCRs, that include grub doing an extend on the initramfs before execing the kernel. The initramfs can execute, but then fails to decrypt the disc, because the PCRs got extended wrong by the replacement initramfs.
Note that I can describe this process in some detail because it already exists, and has for years. Lennart is far from the first to propose it, and you can use grub in this manner. However he wants to replace grub with his own bootloader, so he has to play catchup. I do think he has a harder uphill battle to push that agenda after departing RedHat for Microsoft.
I still think it's a bad 'default' idea, but I would not be surprised at all if, for example, Azure went to trusted boot for all Linux instances by default.
Comment removed (Score:4, Insightful)
Kevin's dad here.... (Score:1)
Re: (Score:2)
Kernel and kmod signature validation is already accomplished via shim/grub2 with MOK keys.
The initrd is a legitimate problem in the chain of trust.
Re: (Score:2)
Re: (Score:2)
New? Meet the new boss, same as the old boss.
Re: (Score:2)
Re: (Score:3)
you're now at Microsoft and therefore have NO BUSINESS recommending architecture changes to the OS
Anyone can recommend anything. It would be supremely stupid to not solicit all recommendations regardless of source. No one needs to accept it. But to reject it out of hand is incredibly short sighted.
or the way systemd was rammed through
Whose "fault" was that? Not the developer you're complaining about. Can you at least consistently target your anger at those who deserve it. Poettering had zero say in anyone adopting his software.
Kindly restrict your fuckery to Windows and other Microsoft products
Systemd is not a windows product. Why would the developer of it restrict his "fuckery" to an OS he isn't developin
Re: Fuck off Lennart... (Score:3)
With enough sugar on top you can swallow almost everything, but enjoy your diabetes later.
Re: (Score:2)
"Yes, modern systems where the boot process isn't cobbled together by scripts..."
The UNIX philosophy is just that: let the boot process be handled by a small program which only does the bare minimum to initialize itself only to hand off the more complicated stuff to scripts that each do one thing and do it well. The very philosophy that systemd is in violation of by attempting to do it all by itself, and not do it well to begin with.
Can someone talk me out of how systemd (Score:3)
shouldn't be its own distribution, and anything built on it we can call flavors or whatever?
Re: (Score:2)
You can say the same thing about every program with a binary size larger than 10MB.
Re: (Score:2)
We haven't ditched systemd yet? (Score:4, Insightful)
Sorry, I don't take Linux architecture advice from Microsoft employees. He's done enough damage and as far as I'm concerned is in timeout
Re: (Score:3)
Poettering, the obnoxious fucking toolshed that he is, is right here.
Current SB implementation in linux is lacking due to self-generated initrds being unable to be validated.
Re: (Score:2)
I will build my own kernel, thanks!
Re: (Score:2)
Do you think SecureBoot prevents you from building your own kernel?
Re: (Score:2)
Sorry, I don't take Linux architecture advice from Microsoft employees. He's done enough damage and as far as I'm concerned is in timeout
He's done zero damage, he has only provide pieces of software. If you're complaining about your favourite distro adopting said software then complain to them. But honestly the power of Open source is the ability for anyone to contribute and anyone to adopt or ignore said software.
The only truly damaging thing in open source software is your position, the kind that thinks the availability of choice for different usage scenarios is somehow "damage". Your comment goes against the ethos of open source.
Re: (Score:3)
"The person in a powerful political position who is responsible for creating and pushing software that has done damage to Linux, hasn't actually done damage to Linux. Actually the only person who has done damage is you and people like you, random person I just met, and any grievance you have about software being adopted and the reasons why, is your own fault."
I don't throw the word "gaslighing" around very often, but you're an idiot.
Nothing new... (Score:4, Insightful)
Trusted grub has been a thing for a while, with TPM being used to validate the initramfs, and then into LUKS for the root filesystem.
The general challenge is that the 'hardening' of TPM makes it fragile at times, mistaking a legitimate usage pattern for an attack attempt and shutting things down breaking validation and/or decryption. So long as there's a recovery 'password' then this can be mitigated, but the vast majority of users won't keep track. For Windows devices, holding your rescue key in escrow is one facet of the 'microsoft account', so if you, say, swapped drives breaking the TPM decryption, microsoft can decrypt it for you. For a Linux desktop, it's hard to point to an authoritative service that people would actually want to use, particularly since the mindset of the common distribution is fairly against that.
As it stands, brace for mkinitramfs to flub the PCRs and produce an unbootable system..
Of course, he now works for Microsoft, so he likely has an Azure bend to this thinking, where Microsoft gets to be the curator of recovery keys for Linux systems as well.
Re: (Score:3)
Or more importantly, it's identifying a huge shortcoming in Linux's current SB implementation, and proposing a fix for it.
That shortcoming is that initrd is unsigned.
It's unsigned, because it's locally generated, so you can't use SB to protect it unless you're running your own root of trust on your machine- which you can, and I do, but 99.9% of people do not, and shouldn't be expected to.
Please no. Systemd is already a mess (Score:5, Insightful)
Re: (Score:2)
That is horseshit and you know it. Every modern OS relies on layers of abstraction and obfuscation. That is true for Systemd as it is for X11 and even the damn Linux kernel.
I actually wonder why it is you think it's harder to learn one thing than the other? Presumably you have never read a systemd man page? It's actually quite well documented.
Re: (Score:3)
I don't find X11 to be actually that difficult to understand at all. The programming interface is well documented, there is no "obfuscation."
Systemd is a change, and so adds cost to people already trained in the prior system, but the idea that systemd is as "obfuscated" as Sys V is weak. Clearly it is less obfuscated, because Sys V is just a mishmash with no central documentation.
The reason that the neckbeards don't know how easy systemd is is quite simple. They don't have any actual need to administer a li
Re: (Score:2)
Exactly. Try to understand how Windows boots? The best you can do is look at some abstract docu. For Linux, you can easily get in there and understand every part. That is if you have a sane init system in there, not the systemd abomination.
Re: (Score:2)
On systemd based distros like Ubuntu, it is all hidden away. You have to use the commands to manage services and hope the commands themselves aren't buggy & do what you want. Which in most cases they do, but there are plenty of edge cases where they may not work so well.
My main concern with SecureBoot (Score:3)
Is having preinstalled keys at all. (I'm explicitly not basing MSFT for being the keysigner... that makes sense given the current design)
The assumption is captured in "It is further assumed that key material used for signing code by the OS vendor can reasonably be kept secure (via use of HSM, and similar, where secret key information never leaves the signing hardware) and does not require frequent roll-over."
I'd actually prefer the default be:
1. No Keys included in hardware by default
2. User or OEM manually does something to put device in Setup mode which allows them to install an OS. (It can just be going into BIOS and clicking a setup new OS boot option..).
3. That OS installs the keys it plans to use forever. (these could be from OS vendor or locally generated)
4. Setup mode is automatically disabled at next reboot/shutdown.
The idea that you can set one key in hardware and it shouldn't need to be updated just doesn't make sense to me.
Re: (Score:3)
That's not an issue. On any paltform with SecureBoot you can remove the default keys and inject your own. That's the very first thing I always do on any new device. It's just that the process is not straighforward since you've got to generate, cross-sign and enroll three different keys (PK, KEK, DB), which includes a few key conversions, and then configure the system to start signing kernels on updates/recompilation with your new key. You've also got to protect the private keys yourself.
https://wiki.archlin [archlinux.org]
Re: (Score:3)
Well, it is an issue. The Microsoft as gatekeeper means that all OSes must get signatures from Microsoft for 'mere mortals' to install the OS.
While what you describe is possible it:
-Requires tedious manual setup because the initial state is explicitly distrusting non-microsoft code
-Automation hostile (mokmanager comes closest but you *must* interact with the console, as that was the decided mechanism for 'physical presence')
I think the parent poster simply advocated that on a completely OS agnostic device,
Re: (Score:2)
While what you describe is possible it:
-Requires tedious manual setup because the initial state is explicitly distrusting non-microsoft code
Na.
SB is just a bone-standard PKI system. Microsoft is one of several CAs that will be installed by default.
Generating your own CA is very easy.
The hard part is getting your kernel updates and DKMS auto-signing to work correctly.
I recently had to do this to get Pop working with SB. The UEFI side (enrolling your CA) literally couldn't be easier.
Re: (Score:2)
So you can UEFI side provision the secureboot key to say, 1,000 endpoints without any manual interaction with any of them?
As far as I've seen, firmware has deliberately made secureboot key provisioning a manual PITA. I have done this plenty of times and never found a 'headless' strategy, with MokManager coming the closest.
Re: (Score:2)
So you can UEFI side provision the secureboot key to say, 1,000 endpoints without any manual interaction with any of them?
What a bizarre bar you've erected.
You can't do this with any UEFI setting.
As far as I've seen, firmware has deliberately made secureboot key provisioning a manual PITA. I have done this plenty of times and never found a 'headless' strategy, with MokManager coming the closest.
It's like 6 keystrokes to add a CA. MokManager is, by design, not headless. I think you're a liar.
Re: (Score:2)
You can't do this with any UEFI setting.
Generally, in servers, you can do this with most UEFI settings, but generally not things like UEFI secureboot keys.
It's like 6 keystrokes to add a CA. MokManager is, by design, not headless. I think you're a liar.
As I said, I never found a headless strategy, I have had to settle for MokManager. *Any* interaction with local console required I consider a PITA. Everything else can be autonomous, happening without a human ever even knowing, but once you get any SecureBoot or similar settings involved, it all derails.
Not all of us are people who only deal with personal laptop/desktop devices and in the dat
Re: (Score:2)
There's this option if you buy a Purism laptop and Librem Key:
https://docs.puri.sm/PureBoot/... [docs.puri.sm]
It's a little tedious to set up, but it uses my own GPG key to sign everything in /boot. If I run an update that adds a new kernel or updates anything there, I'll get a red screen telling me which files have failed their signature check, and that this could be a sign of a system compromise. I'm then offered the opportunity to sign the new files if I know they're legit (like on the first reboot after running an u
Re: (Score:2)
replying to undo my fat-fingered mod. Sorry!
Re: (Score:2)
Hat tip!
Re: (Score:3)
Well, it is an issue. The Microsoft as gatekeeper means that all OSes must get signatures from Microsoft for 'mere mortals' to install the OS.
When this system first came about, there was a lot of concern, but so far MS has shown themselves to be a responsible custodian of the Sacred Root Keys. There is no guarantee that that will always be the case, but so far, so good. And for people truly concerned, they should be advised that they're only the gakekeeper for Joe Sixpack. Nerds can install their own keys if they need to, though wow, I'm really glad I don't need to manage my own re-signed distro mirror...
Re: (Score:2)
Look past the author (Score:2, Troll)
Yeah, I know, all the 1337 Slashdot kids hate Poettering, but there are actually good ideas in this design. Having only one file to update instead of a separate kernel and initramfs can help avoid a lot of scenarios where things go wrong and you end up with an unbootable system.
For a more adult discussion, I recommend LWN's article [lwn.net] on the subject.
Re: (Score:3)
The UEFI side of things is of course easy.
The difficulty comes with all the machinery you need to construct to auto-sign all validated components during OS updates. This is indeed an area that needs fixing.
The dumbfucks on this site karma whoring with SYSTEMD BR8KS UN1X!!! are just noise. They don't matter. Nobody gives a fuck what their opinion is in the larger ecosystem.
Poettering's exact soluti
Re:Look past the author (Score:4, Interesting)
The difficulty comes with all the machinery you need to construct to auto-sign all validated components during OS updates. This is indeed an area that needs fixing.
This is a bit difficult regardless of the OS used.
In the case of Windows, there's no official list of binaries that need to be resigned for a custom Secure Boot to work correctly. The few I do know of are bootmgr, winload, winrestore, and some memory checking utility, but there are a few dlls that may need to be resigned as well. (Windows 7 and older only need to have bootmgr.efi signed, but that's because they don't properly support Secure Boot and use hardcoded certs to verify the kernel / drivers instead.) Then you'd still need to deploy them, and watch for when Windows attempts to update them. (Assuming you are not using WSUS, but even then you'd still need to protect the signed binaries from being overwritten by the official ones.)
Obviously any Apple product won't give you a choice here, so that's irrelevant. Android, if your device fully supports it, requires unlocking the bootloader first, then using adb to flash your key to a particular slot. (For pixel devices this slot is named "avb_custom_key", but that's not a hard requirement and some devices may not have that slot at all.) Then you'll have to integrate generate new signature data for all of the needed binaries and the final partition images. (Google / AOSP's official instructions tell you to integrate the signing key into the build system, and then rebuild Android from source. There's no official instructions for signing a pre-existing build of Android. Such as the stock image for your device.)
Finally we get to Linux. Here we have a few options (and a lot more info to work with):
1. Build the kernel with the EFI shim, then sign the kernel itself and all needed kernel modules.
2. Sign GRUB, the kernel, and all needed kernel modules. Boot using GRUB. (Optionally lock down GRUB's config.)
3. Sign shim, and the kernel. Boot using shim. (This uses shim's MOK support to handle verifying kernel modules. So they don't need to be signed here, but they can be if desired.)
4. Sign shim, GRUB, the kernel, and all default kernel modules. Boot using shim. (This is the option most distros go with. It allows verifying official kernel modules produced by distro maintainers with the distro's Secure Boot key, while also allowing custom kernel modules to be installed with shim's MOK support by the end-user.)
Sadly, many distros tend to update shim and grub as often as they update the kernel. (If not more often.) So attempting to only sign one binary and chain off of it is practically a non starter. Some distros ship the unsigned binaries along side their signed versions, and provide automated MOK support when a new kernel is installed, but that's about all of the help you'll get with a custom Secure Boot implementation. (Some distros also try to update DBX with a new revocation list as well, but that only works in Secure Boot's setup mode, or if the Microsoft keys are installed.)
Personally what I'd like to see is something similar to WSUS where we have a repo specifically for boot binaries. Any time that repo gets an update a notification could be sent out, and automated systems could sign and repackage the binaries into their own local repos for other systems to pull from. Along with some automated client side config to use them instead of the official distro packages. This is doable today, but it requires a custom set up for each distro. Namely:
1. Setting up the local repo manually using package manager specific tools.
2. Setting up each client's package manager to use the new repo and prioritize it's content over the official distro packages using package manager specific configs.
3. Setting up a download script to pull the official packages using package manager specific tools.
4. Signing the binaries. (Unprotected signing key stored on the host is the fastest to set up, but y
Re: (Score:3)
But ultimately, it isn't SecureBoot that's the pain in the ass.
It's easy as hell.
Every single UEFI computer I have has key enrollment functionality in its BIOS, and since it's part of the SB specification, any BIOS without it is noncompliant.
It's th
Re: (Score:2)
I compiled the shim manually (since Pop doesn't include a recent enough one that uses the UEFI var that allows the MOK keys to be enrolled in the kernel keyring, and without that you can't validate kernel modules with the MOK, making the endeavor pointless)
That's news to me. I'd assume Pop OS doesn't have a lot of kernel module users, or has an old kernel then. Why couldn't you just reuse the older shim and it's matching kernel?
But ultimately, it isn't SecureBoot that's the pain in the ass. It's easy as hell.
Depends on what your definition of "SecureBoot" is. If it's just the UEFI firmware implementation, then yes it can be. (Assuming you don't run into any major UEFI bugs or "features" on your devices that is.) If your definition of "SecureBoot" is the boot verification mechanism and the entire ecosystem that uses and relies on it, then
Re: (Score:2)
That's news to me. I'd assume Pop OS doesn't have a lot of kernel module users, or has an old kernel then. Why couldn't you just reuse the older shim and it's matching kernel?
Older shim lacks UEFI key that newer kernel uses to propagate platform keys to kernel keyring.
Pop "doesn't support SB", so has new kernel and old shim.
Depends on what your definition of "SecureBoot" is. If it's just the UEFI firmware implementation, then yes it can be. (Assuming you don't run into any major UEFI bugs or "features" on your devices that is.) If your definition of "SecureBoot" is the boot verification mechanism and the entire ecosystem that uses and relies on it, then no. It's a huge pain in the ass, unless you are willing to completely cede control of your hardware to the OS developers and your motherboard's manufacturer. The second you try to step outside of that nice walled garden of theirs the whole facade comes crashing down and all that's left is a giant mess for you to deal with. (Hell given the nature of this issue, I'd assume even the OS developers and hardware manufacturers have difficulty with it. Along with their own internal solutions and pipelines.)
SB control ends whenever the user software stack stops using the UEFI functions for signature verification, which is generally past the shim in Linux world.
Everything after that is clunkiness imposed by a lack of agreement of how to deal with things.
I doubt OS developers and hardware manufacturers have any problems with it.
As I said, and as you know, it'
How many malicious kernels are out there? (Score:4, Insightful)
I see headlines about this exploit and that, but I don't remember seeing that people are loading trouble kernels unwittingly. Is it actually a problem?
I used to build my own kernels from source back in the early days of linux. I don't know how many people still do that.
(Sigh) In my old age I've become a simple user. But, while I try to be civil about it, I'm still in the anti-systemd camp.
Re: (Score:3)
Philosophically I am anti-systemD but I still use Xubuntu as my primary desktop. I have pretty old hardware at this point but everything just works including a major chunk of games, both linux native and windows. It works with little effort I might add.
I first learned Linux on Slackware. Got really good at reading config files and getting tedious things figured out so I could use the system. Once it was up and running it was more or less fine though I still really enjoy just typing sudo apt-get update, etc.
Re: (Score:2)
Hello ? chkconfig ?
enable/disable/add/remove/change any runlevels anytime
Originally from Irix
He's pots. (Score:3)
That's it.
if it ain't broke... (Score:3)
Let Lennart Puttering break it so a multi-billion-dollar company can sell more support contracts.
Re: (Score:3)
What wasn't broken?
- An audio system stuck in the dark ages that couldn't handle the simple task of automatically switching an audio stream to a bluetooth headset on connect?
- A init system that literally every distribution was attempting to replace since it didn't meet their use cases, resulting in some 15 odd different alternatives being developed and one specific one being adopted by a few notable distros?
- A boot process in a system that people like calling secure that doesn't sign the kernel image it l
Re: (Score:3)
What wasn't broken?
Reading logs. Now it's like waiting for paint dry to extract anything from a crummy low performance binary database. Give it time and it will eventually manage to be even slower than windows event viewer.
Writing logs also sucks to the point where it is common for logging overhead associated with normal background probe spam to consume more CPU time in the system than anything else. It's ridiculous.
- A boot process in a system that people like calling secure that doesn't sign the kernel image it loads?
Better to simply boot from read only media or blow a write breaker before switching to user mode. Trivial s
Re: (Score:2)
"The fact something works for you doesn't mean it's not broken for someone else. This is Linux, you are free not to adopt any piece of software developed for it. That's the beauty of open source."
And herein lies the problem: that freedom is mostly gone. If you want any kind of GUI nowadays, you're more often than not stuck with systemd, because literally EVERYTHING depends on it. It is not impossible, but it is not for the faint of heart either. The best solution so far seems to be to use a distribution tha
OSB... (Score:1)
BaaaaS (Score:2)
nah, screw that (Score:2)
Lennart, be a man, and go write your own shitty kernel
Re: (Score:2)
Lennart, be a man, and go write your own shitty kernel
He would have had he not gone potty years ago. /s
Re: (Score:2)
I'm sure he's heartbroken to be criticized by people who can't figure out which part of the system the code involves.
Yes, become Windows or Apple (Score:2)
The sooner systemd dies, the better of the world will be.
Haha (Score:2)
Even without seeing the link - after a few words I knew this was from El Reg.
Seems a bit complex... (Score:2)
What would be nice is to allow Linux variants to use the TPM for booting and decrypting a LUKS2 protected root filesystem. I'm not sure if all this stuff is needed. At most, it should require a UEFI boot, a check with initrd (which mkinitramfs can be made to do automatically or with an option to seal the TPM with the new values.) Of course, part of the OS install should be injecting a recovery key or pass phrase, so if the TPM doesn't work, the machine is still bootable.
Of course, this can be done, but i
Re: (Score:2)
And we have that. Grub can extend a PCR based on initramfs, and update process can calculate and re-seal the luks decryption key based on that measurement.
So if you boot right with an initramfs that was right while the OS was up and presumably pretected, then the disk unlocks.
If an 'evil maid' has replaced your initramfs, then your root filesystem won't unlock, and will ask for a password instead.
Re: (Score:2)
Now, if we can get mainstream distributions to be able to implement that at install time, it will greatly improve things.
Just you wait (Score:2)
Wait till Richard Stallman hears of this.
https://youtu.be/A3GZx3tfO6w?t... [youtu.be]
Pushing tpm for M$ Pluton next (Score:2)
Pushing tpm for M$ Pluton next.
Basiacally TPM in the CPU you cant steal keys out of with hardware attacks for DRM.
WinPE (Score:2)
Vendor lock-in is still a bad idea... (Score:2)
UEFI was never designed to be our friend. At the core of it lies the secureboot process, a buzzword that sounds like a good idea, because if weren't a buzzword it would be: startup the system with a known set of drivers, digitally signed so that tampering with them will prevent a system from coming up. This is in and of itself not necessarily a bad thing. However, there is also a downside to this: control of the secureboot architecture and platform lies with a single company. A company that has stated that
Re: (Score:2)
IIRC the adoption of systemd was forced on distributions that wanted to keep putting out the Gnome desktop as part of their config/packaging/etc.
And I'm still wondering why a need for a GUI interface impacts the boot process of my headless server that doesn't even have enough horsepower to run said GUI interface...
TPM ... (Score:2)
....Is not something anyone wants, wants to support, or needs to ...
Unless you work for Microsoft and need to pander to DRM
Re: Very misunderstood (Score:2)
Yeah, and half of them probably couldn't even tell you if their distro uses systemd. And most of those are on some flavour of Ubuntu.
It's always fashionable to hate on something. Something else will come along soon enough. Another patent war, more Rust, another Stallman gripe.
Re: (Score:2)
This article clearly wins an award for most comments by people that donâ(TM)t understand it at all.
lol you must be new here!