Re: [gentoo-dev] UEFI secure boot and Gentoo

[Maxim Kammerer <mk@dee.su>]

On Sun, Jun 17, 2012 at 8:03 PM, Greg KH <gregkh@gentoo.org> wrote:
> Huh?  No, why would a user need to resign the UEFI drivers?  Those
> "live" in the BIOS and are only used to get the machine up and running
> in UEFI space, before UEFI hands the control off to the bootloader it
> has verified is signed with a correct key.

Is that always the case? E.g., kernel's efifb module uses the EFI
console driver, similarly to legacy BIOS's VESA interface. It is
possible that in the future more OS-usable EFI drivers will become
commonplace, especially for non-performance-critical periphery
interaction (sensors, etc.). Architecture-independent EFI bytecode
drivers apparently don't have OS interface now, but this could change
as well.

>> If the user does not perform this procedure (due to its
>> complexity and/or lack of tools automating the process), is it
>> possible for an externally connected device to compromise the system
>> by supplying a Microsoft-signed blob directly to the UEFI firmware,
>> circumventing the (Linux) OS?
>
> Again, what?  Please explain.

I am thinking about a possibility where a “rogue” device can upload
its driver directly to the UEFI firmware. I don't see something like
that in the UEFI spec, but perhaps the firmware can support such
behavior outside the spec. E.g., many 3G network tokens support
presenting themselves as network devices or as storage media on the
USB bus (sys-apps/usb_modeswitch deals with that). The reason they do
that is for the OS to install the network driver from the storage
media “representation”. Now, imagine that the OS defers handling of
unfamiliar network devices to the UEFI network driver (as it might do
with unfamiliar video cards and UEFI GOP). It makes sense that UEFI
firmware vendors would support a similar mechanism of loading
(possibly EBC) UEFI drivers from the network device. Why not — the
drivers will be signed, and UEFI can verify the signatures.

So it seems to me that UEFI, because of its complexity and multitude
of features, may provide an OS-circumventing attack vector, which can
only be dealt with by revoking (probably Microsoft) keys in UEFI
firmware, and re-signing only the necessary drivers with a custom key.
Compromising major player's certificates is a real possibility — e.g.,
see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft.

> What API?  The signing tool is public, and no, it doesn't add keys,
> that's up to the BIOS to do, not the userspace tool.

So the re-signing mentioned above must be done in a tedious manual
process? Or can some automatic tool be developed (not necessary
userspace, it can be an EFI app)?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte