4 ms·

That doesn't make any sense whatsoever. If turning off UEFI is hard, how will the user even manage to change the boot order to DVD first in the BIOS? Or not nuk

That doesn't make any sense whatsoever. If turning off UEFI is hard, how will the user even manage to change the boot order to DVD first in the BIOS? Or not nuke the Windows partition unintentionally while partitioning(this happened to some of my friends way back)? The OEMs approached RedHat offering to add their keys but they and the Linux foundation did not form a mechanism responsible for signing open source kernels. If someone steps up to the plate, the OEMs are willing to add keys.

mjg59 14y ago
Some OEMs. In return for large quantities of money, and then you've just swapped one large profit-driven company for a smaller profit-driven company or an industry consortium that would be more worried about not upsetting its members than doing the right thing, and then someone's signature gets revoked because they don't use signed drivers or it turns out that the small community Linux distribution with the forgettable name is actually a front for organised crime and who's taking responsibility for all of this? We thought about this. In detail. My conclusion was that in the absence of a standards body with absolutely no commercial involvement whatsoever stepping up, Microsoft is probably actually the least bullshit option because at least if (or when) someone screws up they'll be blamed. (You don't have to go into the firmware settings to choose to boot from removable media any more. You can just do it from the Windows 8 bootloader options, so it's the same on every machine. This is actually a genuine improvement that Microsoft made to the ease of installing alternative operating systems)
- tmzt 14y ago
  Does the Microsoft signing process require that the shim ensure that the chainloaded bootloaders are signed? Does this also require that kernel drivers are signed? How does this affect access to lower system memory as the root user? And what key must be used to sign the kernel modules? (Is the CA chain verified by the shim or secureboot somehow?)
  - mjg59 14y ago
    The signing process doesn't, but Microsoft reserve the right to revoke the binary's hash if it's used to attack other systems. Implementations that don't verify drivers are going to be fairly easy to circumvent into use as an arbitrary bootloader for unsigned or compromised content, and if the blackhats do so then revocation is a likely outcome. There's no explicit list of required implementation policies. People are free to implement whatever policy they want, based on their perceptions of the risk of revocation.

mjg59 14y ago

Some OEMs. In return for large quantities of money, and then you've just swapped one large profit-driven company for a smaller profit-driven company or an industry consortium that would be more worried about not upsetting its members than doing the right thing, and then someone's signature gets revoked because they don't use signed drivers or it turns out that the small community Linux distribution with the forgettable name is actually a front for organised crime and who's taking responsibility for all of this? We thought about this. In detail. My conclusion was that in the absence of a standards body with absolutely no commercial involvement whatsoever stepping up, Microsoft is probably actually the least bullshit option because at least if (or when) someone screws up they'll be blamed. (You don't have to go into the firmware settings to choose to boot from removable media any more. You can just do it from the Windows 8 bootloader options, so it's the same on every machine. This is actually a genuine improvement that Microsoft made to the ease of installing alternative operating systems)

tmzt 14y ago
Does the Microsoft signing process require that the shim ensure that the chainloaded bootloaders are signed? Does this also require that kernel drivers are signed? How does this affect access to lower system memory as the root user? And what key must be used to sign the kernel modules? (Is the CA chain verified by the shim or secureboot somehow?)
- mjg59 14y ago
  The signing process doesn't, but Microsoft reserve the right to revoke the binary's hash if it's used to attack other systems. Implementations that don't verify drivers are going to be fairly easy to circumvent into use as an arbitrary bootloader for unsigned or compromised content, and if the blackhats do so then revocation is a likely outcome. There's no explicit list of required implementation policies. People are free to implement whatever policy they want, based on their perceptions of the risk of revocation.