Microsoft has a "minimum set of requirements" document about "Designed for Windows" PCs. You can't sell a machine with Windows or tell it's Windows compatible without complying with that checklist.

So, every PC sold to consumers is sanctioned by Microsoft. This list contains Secure Boot and TPM based requirements, too.

If Microsoft decides to eliminate enrollment of user keys and Secure Boot toggle, they can revoke current signing keys for "shims" and force Linux distributions to go full immutable to "sign" their bootloaders so they can boot. As said above, it's not something Amutable can control, but enable by proxy and by accident.

Look, I work in a datacenter, with a sizeable fleet. Being able to verify that fleet is desirable for some kinds of operations, I understand that. On the other hand, like every double edged sword, this can cut in both ways.

I just want to highlight that, that's all.

▲

bri3d 3 hours ago | parent [-]

I don't see how this relates in any way to Amutable and it has been a "concern" for 20+ years (which has never come to pass). How do you think this relates at all?

▲

bayindirh 3 hours ago | parent [-]

Before this point in time, Linux never supported being an immutable image. Neither filesystems, nor the mechanism to lock it down was there. The best you could do was, TiVoization, but that would be too obvious and won't fly.

Now we have immutable distributions (SuSE, Fedora, NixOS). We have the infrastructure for attestation (systemd's UKI, image based boot, and other immutability features), TPMs and controversially uutils (Which is MIT licensed and has the stated goal to replace all GNU userspace).

You can build an immutable and adversarial userspace where you don't have to share the source, and require every boot and application call to attest. The theoretical thickness of the wall is both much greater and this theoretical state is much easier to achieve.

20 years ago the only barrier was booting. After that everything was free. Now it's possible to boot into a prison where your every ls and cd command can be attested.

Oh, Rust is memory safe. Good luck finding holes.

	▲	bri3d 3 hours ago \| parent [-]
		> Before this point in time, Linux never supported being an immutable image. What? As just one example, dm-verity was merged into the mainline kernel 13 years ago. I built immutable, verified Linux systems at least ten years ago, and it was considered old hat by the time I got there. > The best you could do was, TiVoization, but that would be too obvious and won't fly. What does this even mean? "TiVoization" is the slang for "you get a device that runs Linux, you get the GPL sources, but you can't flash your own image on the device because you don't own the keys." This is the exact same problem then as it was now and just as "obvious?" I understand the fears that come from client attestation (certainly, the way it has been used on Android has been majorly detrimental to non-Google ROMs), but, to the Android point, the groundwork has always been there. I'd be very annoyed if someone showed up and said "we're making a Linux-based browser attestation system that your bank is going to partner on," but nobody has even gone this direction on Windows yet. > Oh, Rust is memory safe. Good luck finding holes. I break secure boot systems for a living and I'd say _maybe_ half of the bugs I find relate to memory safety in a way Rust would fix. A lot of systems already use tools which provide very similar safety guarantees to Rust for single threaded code. Systems are definitely getting more secure and I do worry about impenetrable fortresses appearing in the near future, but making this argument kind of undermines credibility in this space IMO.