Re: UEFI Secure Technologies

[Laszlo Ersek <lersek@redhat.com>]

On 02/03/17 22:15, Bill Paul wrote:
> This is not strictly an EDK development question, but it may be the right 
> audience to ask. The UEFI 2.5 specification introduced a section called Secure 
> Technologies, which includes the definition for an EFI_PKCS7_VERIFY_PROTOCOL 
> (among others).
> 
> My question is: what are the odds of this protocol being available in a given 
> UEFI firmware build for a fielded system?
> 
> The context for this question has to do with how secure boot would be handled 
> for OSes other than Windows. Obviously, once UEFI validates the BOOTxxx.EFI 
> loader image, the next step would be for the boot loader to validate the OS 
> image that comes after it, which requires the same kind of cryptographic 
> signature validation that the UEFI firmware performs on loader. But the 
> signature check is built into the BS->LoadImage() service and the firmware 
> only knows how to check signatures on Microsoft PE/COFF images (signed 
> according to the Microsoft Authenticode spec).
> 
> I'm assuming that somehow the Microsoft loader takes advantage of the fact 
> that Windows executables (including the kernel and its DLLs) are also PE/COFF, 
> and it somehow loads those with BS->LoadImage() too. That's great, if you're 
> Microsoft.
> 
> But if you're not Microsoft, you can't use this strategy, which means your 
> loader needs its own custom crypto code.
> 
> In theory the presence of EFI_PKCS7_VERIFY_PROTOCOL would mitigate this, but 
> only on systems where the firmware includes it.
> 
> My concern is that since Windows doesn't depend on it, the odds of this 
> protocol being included in a given build might be fairly slim. I'd like to 
> hear some other (hopefully better-informed) opinions on this matter.

(Not overly well informed:)

- In the "Linux ecosystem", each stage of the boot has its own dedicated
crypto code, to my knowledge (shim, grub2, kernel (for signed kernel
modules)).

- Perhaps the next version of the spec should require that if a firmware
supports Secure Boot, then it expose EFI_PKCS7_VERIFY_PROTOCOL too?
(Just a random thought, not at all researched.)

Anyway, for runtime verification of drivers, modules etc, the kernel
will need its own crypto stuff.

Laszlo