News: 1666805411

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Microsoft's Lennart Poettering proposes tightening up Linux boot process

(2022/10/26)


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.

[1]Agent Poettering offers a [2]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.

The [3]initrd is the "initial RAM disk." It's how Linux distributions cope with the issue of booting a machine on wildly different hardware without building a unique custom kernel for every individual machine. The bootloader loads the kernel and the initrd into memory, and then as the kernel starts to run, it has a temporary filesystem ready for it in memory, from which it can load any additional device drivers it needs – including device drivers that might be needed in order to find its real root filesystem, which could be anywhere: not just on a local drive, but on FibreChannel, InfiniBand, a USB key, a network drive via iSCSI or AoE or NFS, or whatever.

[4]

The problem is that other device drivers may need to be in the initrd, too, such as graphics drivers. If you have Nvidia graphics drivers, for instance, every time the drivers are updated, the distro builds a new initrd.

[5]

[6]

This works, but the problem is that locally generated initrds are potentially insecure. In principle, malware or an intruder could insert malicious code into the initrd, and it will be loaded every time your system boots, even if no other copy of that malicious code exists anywhere else on your hard disk.

The situation regarding full-disk encryption (FDE) is worse: the initrd is how Linux boots off local drives with FDE. As The Reg FOSS desk discovered when [7]putting Linux on a new Dell Latitude , some forms of full-disk encryption can unlock encrypted disks without a password using information stored in the TPM chip's [8]Platform Configuration Registers . Agent P is very concerned about the way that code in the initrd has access to TPM PCRs.

[9]

He outlines the current boot process as follows:

Boot chain is typically Firmware → shim → grub → Linux kernel → initrd ( dracut or similar) → root file system

He lists seven different problems with this sequence of events, and the first threat he mentions is the "evil maid" attack, as [10]discussed on The Reg as long ago as 2009 .

His proposed solution is the Unified Kernel Image:

These UKIs are the combination of a Linux kernel image, and initrd, a UEFI boot stub program (and further resources, see below) into one single UEFI PE file

For the avoidance of doubt, a PE file is a Microsoft "Portable Executable," as we explained [11]when introducing the Redbean 2 multiplatform binary . Yes, that's how UEFI works; indeed, as he notes while explaining the boot process:

Shim

A boot component originating in the Linux world, which in a way extends the public key database SecureBoot maintains (which is under control from Microsoft)

[12]Update time for Ubuntu: Last version of Linux kernel 5.19.17 hits

[13]Lash#Cat9: A radical new Linux UI for keyboard warriors

[14]Intel DAOS 2.2 and Red Hat Stratis 3.3 released

[15]OpenBSD 7.2: The other other FOSS xNix released, runs on Apple M2 Macs

Yes, as with much of this stuff, Microsoft has a hand on the reins, and already some are calling this another step in the company's long-established Embrace, Extend, Extinguish maneuver – for instance, the very first [16]comment on the Hacker News thread on the topic.

As per usual with Poettering pronouncements, we predict panic and parsimony. In some scenarios, this could provide useful protection. As The Reg noted over a decade ago, when UEFI was new, [17]Secure Boot could be a problem for Linux , and we linked to a [18]blog post on the subject by the boot-up boffin supreme Matthew Garrett. However, in time, enterprise distros embraced Secure Boot, and [19]ChromeOS Flex actually recommends it . This time around, Dr Garrett is [20]encouraging :

this is very nice. Needs some work […] but definitely a big step in the right direction.

If MJG approves of it, we would not dare to differ. All we would note is that this potentially widens the divide between enterprise distros, increasingly locked-down, secured, and ever more difficult to customize, and the wild, free-wheeling world of Free Software OSes by and for those who don't want others, or corporations, to be able to control their computers.

As Aldous Huxley wrote:

Most men and women will grow up to love their servitude and will never dream of revolution.



Actual happiness always looks pretty squalid in comparison with the overcompensations for misery.

On x86, at least for now, you can turn off Secure Boot. You can't on Arm machines, which in our opinion a decade ago was [21]one reason that the Surface RT didn't sell . Trusted Computing, after all, is not about you trusting your [22]own computer. There's already a [23]movement against systemd, and we suspect that this will now widen to be anti-UKI as well. ®

Get our [24]Tech Resources



[1] https://www.theregister.com/2022/07/07/lennart_poettering_red_hat_microsoft/

[2] https://0pointer.net/blog/brave-new-trusted-boot-world.html

[3] https://www.kernel.org/doc/html/latest/admin-guide/initrd.html

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y1mt93AtmJakImTAokPz3wAAAAU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y1mt93AtmJakImTAokPz3wAAAAU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y1mt93AtmJakImTAokPz3wAAAAU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[7] https://www.theregister.com/2022/07/22/linux_nonapproved_laptop/

[8] https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers

[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y1mt93AtmJakImTAokPz3wAAAAU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[10] https://www.theregister.com/2009/11/06/mossad_syria_trojan_hack/

[11] https://www.theregister.com/2022/06/20/redbean_2_a_singlefile_web/

[12] https://www.theregister.com/2022/10/25/linux_kernel_51917_ubuntu/

[13] https://www.theregister.com/2022/10/25/lashcat9_linux_ui/

[14] https://www.theregister.com/2022/10/24/daos_22_stratis_33/

[15] https://www.theregister.com/2022/10/21/openbsd_72_released/

[16] https://news.ycombinator.com/item?id=33340866

[17] https://www.theregister.com/2011/09/21/secure_boot_firmware_linux_exclusion_fears/

[18] https://mjg59.livejournal.com/138973.html

[19] https://www.theregister.com/2022/02/16/google_chrome_os/

[20] https://twitter.com/mjg59/status/1585055019677929477

[21] https://www.theregister.com/2013/11/14/microsoft_surface_rt_stockpile/

[22] https://www.gnu.org/philosophy/can-you-trust.en.html

[23] https://nosystemd.org/

[24] https://whitepapers.theregister.com/



...using TPM 2.0 hardware

Alumoi

Ha, so now Linux will only run on machines that can (officially) run Windows 11. And maybe there will be a little pop-up during boot telling you to upgrade to Windows 11 for a better experience?

*I* propose ...

oiseau

Lennart Poettering proposes tightening up Linux boot process ...

Yes?

Well ...

How about I propose he tightens up his bloody mouthhole?

... and for those who don't want others, or corporations, to be able to control their computers.

Yes, I am and will always be one of those.

What about it?

O.

Re: *I* propose ...

VoiceOfTruth

While I share some of your sentiment the thing is... kernel development is mostly in the hands of people who are paid to do it. The "anyone can contribute" is a bit of myth. In theory that is true, but in practice it is not really. So the "doers" do and the "don't doers" don't. We can see this with the top contributors to the kernel are companies.

I don't count writing a driver as contributing to the kernel any more than somebody who writes a Windows driver is contributing to the NT kernel. I know it's different, but a driver is a driver not a kernel.

Re: *I* propose ...

Dazed and Confused

> Lennart Poettering proposes tightening up Linux boot process ...

Given Lennart Poettering's history when it comes to security he's hardly a good one to lecture us is he. This is the man who invented systemd and moved us from the classic init model with a tiny attack surface to the monster systemd with a massive attack service. He's clearly never heard of "least privileges" he's clearly never heard of modularization or he'd never have included network functions into the orphan catcher, let us remind ourselves that PID 1 is so critical that if you can kill it the kernel dies! Systemd is much bigger than a classic init and therefore will contain a lot more potential bugs and possible ways of dying.

I know he's now departed from RH but has he forgotten everything he ever knew about RHEL? You need to be able to build your own initrd files. Just look at how many config files are on there and are acted upon before we perform the pivot to the "real" root disk. You want to set load time options on drivers (I know drivers should use SYSFS and udev for tuneables but they don't all do it and some are a pain to implement that way) then you need to write a modprobe.d/*.conf file and you then need to get that onto your initrd as the driver is loaded from there and not from the real root. Even the bloody hostname is read from the initrd, look at your logs file in the first week after boot FFS!

Then there is the issue that system vendors often provide "tweaked" versions of drivers. For example HPE have drivers on the SPP, for RHEL8 these are digitally signed but not by MS they're signed by HPE and since they produced the FW they've loaded their own secure boot public keys into the FW's keystore. BTW they've also loaded the SUSE public keys, not just the MS ones.

Since these drivers are signed for secure boot there is no problem with using them with secure boot enabled.

Re: *I* propose ...

vtcodger

If Potty favors it, I'm against it?

Yeah, I think I can live with that.

(And I can sure as hell live without TPM, UEFI and secure boot -- at least on my own home machines. Might feel differently if I were crazy enough to sign up for the thankless and very likely impossible task of securing the software on corporate machines.)

TPM? No thanks

b0llchit

I have ten fingers.

Please identify the two relevant, centrally located ones, to show. I'm already showing them for you to identify.

Re: TPM? No thanks

wolfetone

You're only using two of them?

Why not use 3? Tell him to read between the lines.

Lorribot

Someone points out what they perceive to be a weakness in the boot process of Linux, offers up some suggestions on fixing it and all Linux people can focus on is that Microsoft are trying to take over the world (Google already have that covered) and destroy Linux.

Would seem to me that the noisy minority that advocate Linux seem to be doing a great job of turning people off the OS with their rude and condescending attitudes.

Open Source obviously doesn't always mean open minds.

Depends on the someone

Richard 12

In this case, there is a lot of prior history proving that while the overall idea might be reasonable, neither of the entities related to the proposal should be permitted within ten thousand miles of the implementation, because they will screw it up.

Will Godfrey

May I remind you (as reported in this very rag) that other security 'improvement' - so-called secure boot - has proved to be a vector for malware?

Fool me once - shame on you.

Fool me twice - shame on me.

oiseau

Fool me twice - shame on me.

Well ...

I beg to differ.

In matters regarding security -> Fool me twice? -> I'm a certified idiot.

"Someone points out"

tekHedd

Saying "Someone" when it's Lennart talking about Linux is intentionally misrepresenting the issue.

Lennart Poettering points out something he perceives as a "weakness" in Linux? Translation: they've found what they think is a weakness in the Linux ecosystem and are about to go on the attack. This is not about improving Linux for anyone but Microsoft.

The word "disingenuous" doesn't even begin to describe what's happening here.

Ideasource

If the goal is to secure the system against utility, then Microsoft argument makes sense.

reduce that to its simple form of verbage and proper orientation and we are essentially talking about Microsoft demanding sabotage rights.

So yeah they got called out their inappropriate objective and manipulative methodology.

Re: Open Source obviously doesn't always mean open minds.

Anonymous Coward

Except this is a proposal which basically stops everything being open source.

The reason the whole open source movement started was so that people could control their own software, they could make changes they needed. This proposal is explicitly intended to remove that freedom.

Re: Open Source obviously doesn't always mean open minds.

Anonymous Coward

I'd say it's UEFI step 2.

UEFI was originally designed to ensure you could no longer install Linux without, well, permission from Microsoft. Coupled with the usual discount blackmail of OEMs who only got license "discounts" if they installed Redmond's global virus on all new systems, the idea was to make it as hard as possible to install Linux on a new machine. The problem was that that became too blatantly obvious monopol;y behaviour which would (again) get them into troubel so they backed off just enough to make that harder to prove.

This is simply step 2 after a long campaign of make believe playing nice with Linux.

It's not that I don't understand it, it's all about lots of money. It's just the underhand way in which they go about it that really pisses me off. It's almost as if they are scared of honest competition, which raises the question: why?

werdsmith

Would seem to me that the noisy minority that advocate Linux seem to be doing a great job of turning people off the OS with their rude and condescending attitudes.

Yes. But you can’t say it here. You will make people cry, which is not very nice.

Yes Linux’ worst enemy is indeed the approach of Linux zealots, but you can’t tell them that. And trying to gaslight everyone about Microsoft when their own house isn’t in order is really not helpful either. There are other alternatives, I’ve long since become sick of Linux.

Anonymous Coward

There are other alternatives, I’ve long since become sick of Linux.

You're very welcome to use Microsoft software - it's your problem. Some people, however, work at a level of security and confidentiality that pretty much excludes their products, and who have in general a massive aversion of being lied to.

As for Linux, let me put it this way.

I'm about to start up a number of businesses that as of next year need in the region of 30..40 people who have a deep level of IT expertise, and a number of developments suggest I may have to double that before the year is out. If they haven't worked with Linux to more than just end user level they will not even make it past first screening.

Are there zealots? Yes, and they are of no use to us because zealotry and fanatism means having a closed mind to options. Enthusiasm is great, but it should never cloud objectivity. It is exactly that objectivity that made us exclude a number of companies from our IT platform - we look at the complete picture, and risk exposure also comes at a cost.

He's with Microsoft?

The Velveteen Hangnail

This is the first time I heard he works for Microsoft. And yet somehow this doesn't surprise me in the least.

He's against everything that the "unix way" stands for so naturally he works for the king of monopolistic monolithic software kingpins.

And naturally his "recommendation" is to inextricably tie the core of linux into Microsoft. What a douche.

Wait for Microsoft to reinvent the wheel...

Ken Moorhouse

No doubt inserting a U into the Initrd process.

Let's hope we don't need to distinguish between hard and soft varieties...

wolfetone

Out of all the people on the internet, I really wish Poettering would just fuck off. Stick him on a rocket to Mars with Musk and Bezos.

It's no surprise me to he's decided to go to Microsoft. They couldn't kill Linux while Ballmer flirted with high blood pressure, so they've gone on to Embrace and Extend Linux. This entitled gobshite is now moving them on to the Extinguish stage. First with the systemd cancer, now this bollocks?

Yet here we are, giving the cretin air time for yet another one of his idiotic, awful, fetishes.

Vometia has insomnia. Again.

I remember the first time I encountered him in the wild. There was a discussion between various developers and users which was the usual mix of friendly, sometimes a bit snarky, and was mostly fairly informed albeit opinionated with a bit of arguing here and there. Just the usual stuff, nothing out of the ordinary; except for this one guy who kept on popping up in various parts of the discussion with the most unnecessarily abrasive, confrontational and childish attitude problem. I was kinda surprised that nobody else was just telling him to fuck off: they were more thick-skinned than I would've been, and if I'd seen someone behaving like that on a forum I moderated I would've banned them. After the n th occurrence, out of curiosity I looked at the name. It was Poettering. That told me all I needed to know.

Dan 55

This entitled gobshite is now moving them on to the Extinguish stage. First with the systemd cancer, now this bollocks?

That's what he's getting out of joining MS, he can finally Poeterrise the kernel.

He'll probably trap it in some pincer movement between secure boot and systemd, requiring code of his at each step to verify previous and next steps, then once he's got his foot in the door he can start with the feature creep.

Maventi

No mention of the elephant in the room: remote attestation? Lennart makes brief reference of this in his own post: https://0pointer.net/blog/brave-new-trusted-boot-world.html

This is already being used by popular apps on mobile phones, almost completely killing the custom ROM scene as they aren't 'approved' builds. Windows 11 now requires a TPM.

Apple and CloudFlare have been quietly bringing this to the web as well: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/

Joining the dots start to create an ugly picture.

I was tempted to reject outright

hayzoos

My first thought upon reading the article title was "Oh, what the fuck does he want to do know?"

Uponn reading the article, I see he has a point. There is a security issue.

I am familiar with the unified kernel image concept. I had a laptop configured to use one I built with a UEFI shim called straght from UEFI bootstrap. Not much different than building a kernel, then initrd, then configuring a bootloader.

Now for actually implementing UKI as the defacto standard for Linux bootstrapping, NOT for MS and Poettering to to do or even with a consortium of systemd friendlies. I can already be done with existing tools.

As far as the boot process being corrupted whilst building an initrd, the same can happen whilst building a kernel, or building anU UFI image. NOT a good reason to push an MS/Poettering/RH/Debian systemd like solution to the problem.

OK, so I still reject the proposal based on track records.

Re: I was tempted to reject outright

DrSunshine0104

I am not saying this is a slippery slope but you can keep extending this, "What can you trust?" mentality until you arrive at the light passing to your eyeballs. Can you trust your init, your DE, your application, your display manager, etc? Pretty soon you have to have all the applications on your system signed by a 'trusted authority' and we have arrived at the hellscape of MacOS development. The initrd isn't built with bits that are not already on your hard disk. The bad actor would have to be already on the disk and would be in a place where it could be discovered.

This isn't my bailiwick and would gladly be told how I am mistaken but this just seems to keep kicking the trust problem down the road without actually solving anything.

"Needs some work"

Anonymous Coward

Yeah, that's a laugh. Lennarts signature move, actually.

Here's a clue, that work isn't going to happen. Lennart has already decided how this will be built, and is already building it. The parts that need work aren't getting fixed.

His eBPF that dosen't support any of the syntax of the actual BPF and uses a totally different architecture is another great example of a project that early on people said, "sounds interesting but needs some work".

Torvalds doesn't want him in the kernel, now he wants to put a wrapper around the kernel? Like people have said for years, it's not that it doesn't need to be done, just don't let Poettering do it.

Sigh. It's a losing battle, isn't it?

willfe

A Microsoft employee, already infamous for absolute garbage software and unmatched arrogance, proposes yet another in a long line of overly complex "solutions" to imaginary problems that wrest control from the users and hand it to corporations in charge of the crypto keys, and people are cheering him on and mocking Linux users for being closed-minded.

People are just handing over the keys without realizing they'll soon be locked out of their own cars, and trying to explain why that's a bad idea is always just met with incredulity and mockery.

What's the point anymore? Maybe it's just time to move on to different architectures without this hardware security garbage in it, roll over to a Linux fork that doesn't entertain this nonsense, and leave the self-flagellating users to the walled garden they seem to be begging for.

Re: Sigh. It's a losing battle, isn't it?

robinsonb5

I've thought for a while that if we're going to keep any form of computing freedom in the long term, we desperately need an FPGA board with at least 8 gig of RAM (they typically have half a gig or less), capable of running a RISCV system that can self-host right down to rebuilding its own FPGA bitstream. Realistically we'll be stuck at early to mid 2000's performance, but no-one will be able to tell us what we can or can't run on it.

(Most of the required pieces already exist - just need a board with enough RAM!)

Maybe at last

steelpillow

this will wake up the world to the need to exorcise Microsoft (TM) from the boot process once and for all, secure or otherwise.

No, sorry, I must have been dreaming.

Is it just me?

Youngone

Does anyone else think "Evil Maid" sounds slightly sexy?

Probably just me. I'm having weird day.

Re: Is it just me?

PRR

> Does anyone else think "Evil Maid" sounds slightly sexy?

https://youtu.be/-SXbmeFCnTM?t=13

Re: Is it just me?

David 132

Actually, this is the one that came to my mind: [1]https://youtu.be/vWNJZrdn7i4?t=51

The question is, does Poettering's suggestion suck or blow?

(¿Por qué no los dos?)

[1] https://youtu.be/vWNJZrdn7i4?t=51

PRR

> Does anyone else think "Evil Maid" sounds slightly sexy?

https://youtu.be/-SXbmeFCnTM?t=12

Glad I'm a hoarder...

Arbuthnot the Magnificent

My stack of pre-TPM, IME / PSP-free motherboards and laptops should see me out...

Re: Glad I'm a hoarder...

David 132

But on such old hardware, you won't be able to mine crypto! Or trade NFTs in the exciting new world of Web3! Or take part in the cyber future of the Metaverse!

You're cutting off your nose to spite your face!

Agamemnon

BSD is Pottering Free.

n = ((n >> 1) & 0x55555555) | ((n << 1) & 0xaaaaaaaa);
n = ((n >> 2) & 0x33333333) | ((n << 2) & 0xcccccccc);
n = ((n >> 4) & 0x0f0f0f0f) | ((n << 4) & 0xf0f0f0f0);
n = ((n >> 8) & 0x00ff00ff) | ((n << 8) & 0xff00ff00);
n = ((n >> 16) & 0x0000ffff) | ((n << 16) & 0xffff0000);

-- Yet another mystical 'C' gem. This one reverses the bits in a word.