4 ms·
Note that secure boot trusting Microsoft's key is a completely useless feature. In addition to countless holes like these (since Microsoft signs software writt
by devit 6y ago
Note that secure boot trusting Microsoft's key is a completely useless feature.
In addition to countless holes like these (since Microsoft signs software written in C), and the fact that you need to already have compromised the system, all that secure boot does is ensure that an unmodified kernel is running; you can however have it run arbitrary user space, including for instance running the user's previous OS in a VM or emulator and altering its behavior arbitrarily, and thus it effectively provides no protection whatsoever.
- johncolanduoni 6y agoLinux does have mechanisms to prevent changes to userspace (in particular the Integrity Measurement Architecture), but you’re right that distributions don’t generally implement these in a useful way. Some more locked-down distributions like Google’s Container Optimized OS do use these to prevent offline userspace changes.
- the8472 6y agoThere are some android features that recently have been upstreamed to the mainline kernel like dm-verity that allow you to boot into a read-only, verified userspace.
- bscphil 6y agoYes, because of Microsoft's key signing program, UEFI security is already fatally flawed even without this new issue. See for example https://habr.com/en/post/446238/ https://habr.com/en/post/446238/ > In this article we proved the existence of not enough reliable bootloaders signed by Microsoft key, which allows booting untrusted code in Secure Boot mode. Using signed Kaspersky Rescue Disk files, we achieved a silent boot of any untrusted .efi files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK.
- fomine3 6y agoSecure Boot provides an initial part of chain of trust. Rest of parts should be prepared by distribution.