UEFI Secure Technologies

UEFI Secure Technologies

[Bill Paul]

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.

-Bill

-- 
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
                 wpaul@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================

Re: UEFI Secure Technologies

[Laszlo Ersek]

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