2 ms·

the point of on first boot is that Microsoft will have to use the same mechanism as everyone else, and not be able to "prebake" keys, which subsequently (and qu

by throwaway2048 14y ago

the point of on first boot is that Microsoft will have to use the same mechanism as everyone else, and not be able to "prebake" keys, which subsequently (and quite coincidentally i'm sure) have bugs in their update procedure.

drivebyacct2 14y ago
How is that any different. Even every single Linux user I know has bought a laptop and fired it up at least once before subverting the boot process to install Ubuntu right off the bat. So, let's assume 99.999% of consumers will boot their laptop as soon as they get it. okay, we're still in the exact same boat we've been in. Unless I'm missing something... >which subsequently (and quite coincidentally i'm sure) have bugs in their update procedure. Given the multitude of bugs in various UEFI impls so far, I would say that this is a fairly legitimate concern. Especially as I'm assuming most people like you or I are likely to just disable SecureBoot altogether and never properly "test out" enrollment.
- AnIrishDuck 14y ago
  > Even every single Linux user I know has bought a laptop and fired it up at least once before subverting the boot process to install Ubuntu right off the bat. Now imagine there's an option in the UEFI BIOS: * Revert to trust-on-boot mode. WARNING: this may expose you to attacks by malware.
  - drivebyacct2 14y ago
    Again, how is this any different than just letting the user enroll a key? Or using one signed by a supported key, or using one with a shimloader already ready to go? I mean, I guess as a convenience mechanism, but then again, why not just disable it and be done with it. Maybe a chance that would make more sense to me would be to have an option: * Extract SecureBoot keys from bootloader/kernel whatever and be able to specify your own kernel or what not. But then again, that's basically what you get via your own key enrollment ;)
- deleted 14y ago
  [deleted]

drivebyacct2 14y ago

How is that any different. Even every single Linux user I know has bought a laptop and fired it up at least once before subverting the boot process to install Ubuntu right off the bat. So, let's assume 99.999% of consumers will boot their laptop as soon as they get it. okay, we're still in the exact same boat we've been in. Unless I'm missing something... >which subsequently (and quite coincidentally i'm sure) have bugs in their update procedure. Given the multitude of bugs in various UEFI impls so far, I would say that this is a fairly legitimate concern. Especially as I'm assuming most people like you or I are likely to just disable SecureBoot altogether and never properly "test out" enrollment.

AnIrishDuck 14y ago
> Even every single Linux user I know has bought a laptop and fired it up at least once before subverting the boot process to install Ubuntu right off the bat. Now imagine there's an option in the UEFI BIOS: * Revert to trust-on-boot mode. WARNING: this may expose you to attacks by malware.
- drivebyacct2 14y ago
  Again, how is this any different than just letting the user enroll a key? Or using one signed by a supported key, or using one with a shimloader already ready to go? I mean, I guess as a convenience mechanism, but then again, why not just disable it and be done with it. Maybe a chance that would make more sense to me would be to have an option: * Extract SecureBoot keys from bootloader/kernel whatever and be able to specify your own kernel or what not. But then again, that's basically what you get via your own key enrollment ;)
deleted 14y ago
[deleted]