3 ms·

Can someone ELI5 what secure boot does? Does it just prevent malware from overwriting the MBR? I turned it off on my most recent install, even though I still

Can someone ELI5 what secure boot does? Does it just prevent malware from overwriting the MBR? I turned it off on my most recent install, even though I still use full disk encryption. Had some issues with VirtualBox VMs that indicated secureboot might have been the cause.

aaronmdjones 6y ago
UEFI Secure Boot only applies to UEFI booting. So if you're booting via an MBR (courtesy of a UEFI Compatibility Support Module) then Secure Boot won't help you. You need to turn the CSM off for any decent booting guarantees, and then MBRs are ignored and malware overwriting an MBR is of no consequence -- it won't even stop the machine from booting if it zeroes it out completely [1]. The purpose of Secure Boot is to verify that the binaries (e.g. bootloader) that the firmware is executing from your EFI System Partition (Yes, UEFI systems are aware of both partitions and filesystems, unlike BIOS systems) are digitally signed with a key in its database. Likewise, those binaries are themselves supposed to verify that the things they're loading (e.g. kernels) are signed with a trusted key, which can either be a key built into the Secure Boot database, or a key built into the bootloader (where changing such a key would invalidate the signature on the bootloader itself). If you're running Linux, you can even eschew a bootloader entirely, by building the kernel itself as an EFI binary and relying on the UEFI Boot Manager to load it directly. This is called EFI stub mode, and is still compatible with Secure Boot if you sign the kernel binary yourself, with a key that you provision into the database. This is how my NAS boots. Note that nothing here implies any sort of encryption. Whether you use disk encryption or not is independent of whether you use Secure Boot or not -- Secure Boot does not require, or even provide, any disk encryption services. Something like Microsoft's BitLocker can use a TPM to store the decryption key, and Windows will not require that UEFI Secure Boot is enabled to do this. However, changing the system firmware settings after the fact (e.g. turning Secure Boot on or off) will make the TPM (correctly) refuse to divulge the disk encryption key you've sealed into it during BitLocker setup, rendering the machine unbootable again until you either (a) undo your configuration change or (b) enter your BitLocker recovery code and set up BitLocker all over again. [1] Speaking only of the bootloader portion, which is the first 440-ish bytes. The disk identifier and partition table is in the rest of the first 512 bytes, but on a UEFI system booting in UEFI mode, there is (usually) only a single "partition" in the table here anyway: a protective MBR containing a single whole-disk GPT. The actual GPT with the real list of partitions follows after. Implementations differ on whether they actually require a protective MS-DOS partition table, so a GPT-only disk (no protective MBR) could be bootable on some systems anyway.
e12e 6y ago
If legacy boot is off, UEFI and TPM/secure boot offers code signing for everything running on your computer. UEFI checks first stage boot loaders and/or kernels for a signature backed by a key/cert in the TPM. AFAIK know, out of the box, that means Microsoft, RedHat/IBM, Canonical or a handful of others have signed your bootloader/kernel. Whatever you run next is supposed to check that any further code is signed - at least code allowed into kernel space. If there exist any signed snippets with exploitable errors, the whole card house collapses (but you can limit exposure by only allowing code you yourself signed, such as a single build of the Linux kernel). Linux can/will require signed drivers with secure boot enabled - so that can lead to some issues (that can be fixed, eg by adding a signing key and signing the drivers). In theory, you'll never run untrusted code in the kernel - no blue pill hypervisor root kit etc.
shawnz 6y ago
Secure Boot helps validate that the bootloader in which you are typing your disk encryption password is authentic and not a rootkit/keylogger. Secure Boot shouldn't affect VirtualBox in any way. Are you sure your VirtualBox issue didn't have to do with Hyper-V?

aaronmdjones 6y ago

UEFI Secure Boot only applies to UEFI booting. So if you're booting via an MBR (courtesy of a UEFI Compatibility Support Module) then Secure Boot won't help you. You need to turn the CSM off for any decent booting guarantees, and then MBRs are ignored and malware overwriting an MBR is of no consequence -- it won't even stop the machine from booting if it zeroes it out completely [1]. The purpose of Secure Boot is to verify that the binaries (e.g. bootloader) that the firmware is executing from your EFI System Partition (Yes, UEFI systems are aware of both partitions and filesystems, unlike BIOS systems) are digitally signed with a key in its database. Likewise, those binaries are themselves supposed to verify that the things they're loading (e.g. kernels) are signed with a trusted key, which can either be a key built into the Secure Boot database, or a key built into the bootloader (where changing such a key would invalidate the signature on the bootloader itself). If you're running Linux, you can even eschew a bootloader entirely, by building the kernel itself as an EFI binary and relying on the UEFI Boot Manager to load it directly. This is called EFI stub mode, and is still compatible with Secure Boot if you sign the kernel binary yourself, with a key that you provision into the database. This is how my NAS boots. Note that nothing here implies any sort of encryption. Whether you use disk encryption or not is independent of whether you use Secure Boot or not -- Secure Boot does not require, or even provide, any disk encryption services. Something like Microsoft's BitLocker can use a TPM to store the decryption key, and Windows will not require that UEFI Secure Boot is enabled to do this. However, changing the system firmware settings after the fact (e.g. turning Secure Boot on or off) will make the TPM (correctly) refuse to divulge the disk encryption key you've sealed into it during BitLocker setup, rendering the machine unbootable again until you either (a) undo your configuration change or (b) enter your BitLocker recovery code and set up BitLocker all over again. [1] Speaking only of the bootloader portion, which is the first 440-ish bytes. The disk identifier and partition table is in the rest of the first 512 bytes, but on a UEFI system booting in UEFI mode, there is (usually) only a single "partition" in the table here anyway: a protective MBR containing a single whole-disk GPT. The actual GPT with the real list of partitions follows after. Implementations differ on whether they actually require a protective MS-DOS partition table, so a GPT-only disk (no protective MBR) could be bootable on some systems anyway.

e12e 6y ago

If legacy boot is off, UEFI and TPM/secure boot offers code signing for everything running on your computer. UEFI checks first stage boot loaders and/or kernels for a signature backed by a key/cert in the TPM. AFAIK know, out of the box, that means Microsoft, RedHat/IBM, Canonical or a handful of others have signed your bootloader/kernel. Whatever you run next is supposed to check that any further code is signed - at least code allowed into kernel space. If there exist any signed snippets with exploitable errors, the whole card house collapses (but you can limit exposure by only allowing code you yourself signed, such as a single build of the Linux kernel). Linux can/will require signed drivers with secure boot enabled - so that can lead to some issues (that can be fixed, eg by adding a signing key and signing the drivers). In theory, you'll never run untrusted code in the kernel - no blue pill hypervisor root kit etc.

shawnz 6y ago

Secure Boot helps validate that the bootloader in which you are typing your disk encryption password is authentic and not a rootkit/keylogger. Secure Boot shouldn't affect VirtualBox in any way. Are you sure your VirtualBox issue didn't have to do with Hyper-V?