Hacker News Reader

Comment by snowwindwaves | Hacker News Reader

Read the whole thread on lkml and didn't see a good argument as to why lockdown being enabled or not should depend on the way the machine was booted. Linus seemed to suggest having lockdown on by default would be reasonable, independent of boot method.

View on HN

Indeed, having lockdown on by default would be reasonable.

There is an argument that "it's useless" [1] without SecureBoot but so what? Separation of concerns is a good principle and allows external people to reason about the behaviour much more easily.

There is no point implementing logic like "if x == 0 then y = 0; return x * y" when a simple "return x * y" will suffice. In fact it's actively harmful as it raises the complexity.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01621.html

There's an argument that it's harmful without a verified boot chain - it doesn't add that much security in that case, but it does limit functionality. If you have enough underlying infrastructure to mean that it does add a meaningful amount of security, then the loss of functionality is a worthwhile tradeoff, but otherwise it's likely to cause justifiable user anger.

The counter argument to that is if it causes user anger, then maybe it should not be enabled at all.

Also, I am not sure about it adding no security without verified boot - a machine rebooting is something that can be noticed.

An attacker doesn't have to be in a rush, they can wait for the next time you reboot (by, say, forcing a notification telling you that you need to reboot for security updates)

this is the argument that doesn't appear to be getting much traction with the lkml. it was an interesting exchange to read as both sides appear to be speaking past each other repeating the same points. a case of agree to disagree perhaps.

there is really no such thing as a verified boot chain on x86 anymore, microsoft leaked keys that essentially allow any binary to be booted on UEFI that uses microsoft keys, im not sure what the point of all this fuss is.

They didn't. No keys were leaked. I wrote about this at the time (https://mjg59.dreamwidth.org/44223.html) but the short version is that the leaked tooling needed to carry out that attack was specific to ARM, required someone with physical access to the console to confirm the installation, and was blacklisted anyway.

You can, at least on some machines, remove the existing keys and roll your own chain of trust. If you care about secure boot environment, you should probably start with that anyway.

Reply on news.ycombinator.com