4 ms·

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

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 http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01621.html

mjg59 9y ago
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.
- throwaway2048 9y ago
  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.
  - mjg59 9y ago
    They didn't. No keys were leaked. I wrote about this at the time (https://mjg59.dreamwidth.org/44223.html 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.
  - viraptor 9y ago
    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.
- bennofs 9y ago
  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.
  - mjg59 9y ago
    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)
- snowwindwaves 9y ago
  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.

mjg59 9y ago

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.

throwaway2048 9y ago
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.
- mjg59 9y ago
  They didn't. No keys were leaked. I wrote about this at the time (https://mjg59.dreamwidth.org/44223.html 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.
- viraptor 9y ago
  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.
bennofs 9y ago
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.
- mjg59 9y ago
  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)
snowwindwaves 9y ago
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.