Arnt Gulbrandsen <arnt@???> wrote:

> Simon Hobson writes:
>> Not really, but I don't see any sign of that as a question in the post I was replying to !
>
> You said secure boot's security is blown out of the water because it's possible to run untrusted code under certain circumstances.

Pretty much

> IMHO it provides useful security because (absent mistakes by the owner) there are many attackers who cannot make use of those circumstances.

Not really, it comes down to "anyone with physical access to your hardware" can fiddle with the boot process. With the ability to run an "insecure" boot package, you have the opportunity to interject in the process - such as capture your password unlocking the encrypted root volume.
Full disk encryption won't help unless it's handled by the BIOS/EFI, having full disk encryption done by the kernel means that (as a minimum) you need a volume unencrypted with a bootloader, kernel, and init filesystem.

Really, it comes down to that group of "many attackers who cannot make use of those circumstances" is really the same set that can't attack your boot process because they don't have physical access to the machine (or remote admin ability while it's running). In this situation, the security added by secure boot is roughly ... a bit of a hindrance, but no obstacle to someone who knows what they are doing.

The only way round that is for there to be no "insecure" signed bootloaders in existence. But because that situation pretty well kills "open" operating systems, that is not the case.