Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Maxim Kammerer <mk@...>
Subject: Re: UEFI secure boot and Gentoo
Date: Sun, 17 Jun 2012 22:22:32 +0300
On Sun, Jun 17, 2012 at 8:03 PM, Greg KH <gregkh@g.o> 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


References:
UEFI secure boot and Gentoo
-- Greg KH
Re: UEFI secure boot and Gentoo
-- Arun Raghavan
Re: UEFI secure boot and Gentoo
-- Ben de Groot
Re: UEFI secure boot and Gentoo
-- Arun Raghavan
Re: UEFI secure boot and Gentoo
-- Ben de Groot
Re: UEFI secure boot and Gentoo
-- Richard Farina
Re: UEFI secure boot and Gentoo
-- Florian Philipp
Re: UEFI secure boot and Gentoo
-- Rich Freeman
Re: UEFI secure boot and Gentoo
-- Maxim Kammerer
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: UEFI secure boot and Gentoo
Next by thread:
Re: UEFI secure boot and Gentoo
Previous by date:
Re: Re: UEFI secure boot and Gentoo
Next by date:
Re: Re: UEFI secure boot and Gentoo


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.