Gentoo Archives: gentoo-dev

From: Maxim Kammerer <mk@×××.su>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo
Date: Sun, 17 Jun 2012 19:24:36
Message-Id: CAHsXYDB5JmZ9e0HeNsQbFZV1rAnjS+tQ8By-BrVvtgw6784MzA@mail.gmail.com
In Reply to: Re: [gentoo-dev] UEFI secure boot and Gentoo by Greg KH
1 On Sun, Jun 17, 2012 at 8:03 PM, Greg KH <gregkh@g.o> wrote:
2 > Huh?  No, why would a user need to resign the UEFI drivers?  Those
3 > "live" in the BIOS and are only used to get the machine up and running
4 > in UEFI space, before UEFI hands the control off to the bootloader it
5 > has verified is signed with a correct key.
6
7 Is that always the case? E.g., kernel's efifb module uses the EFI
8 console driver, similarly to legacy BIOS's VESA interface. It is
9 possible that in the future more OS-usable EFI drivers will become
10 commonplace, especially for non-performance-critical periphery
11 interaction (sensors, etc.). Architecture-independent EFI bytecode
12 drivers apparently don't have OS interface now, but this could change
13 as well.
14
15 >> If the user does not perform this procedure (due to its
16 >> complexity and/or lack of tools automating the process), is it
17 >> possible for an externally connected device to compromise the system
18 >> by supplying a Microsoft-signed blob directly to the UEFI firmware,
19 >> circumventing the (Linux) OS?
20 >
21 > Again, what?  Please explain.
22
23 I am thinking about a possibility where a “rogue” device can upload
24 its driver directly to the UEFI firmware. I don't see something like
25 that in the UEFI spec, but perhaps the firmware can support such
26 behavior outside the spec. E.g., many 3G network tokens support
27 presenting themselves as network devices or as storage media on the
28 USB bus (sys-apps/usb_modeswitch deals with that). The reason they do
29 that is for the OS to install the network driver from the storage
30 media “representation”. Now, imagine that the OS defers handling of
31 unfamiliar network devices to the UEFI network driver (as it might do
32 with unfamiliar video cards and UEFI GOP). It makes sense that UEFI
33 firmware vendors would support a similar mechanism of loading
34 (possibly EBC) UEFI drivers from the network device. Why not — the
35 drivers will be signed, and UEFI can verify the signatures.
36
37 So it seems to me that UEFI, because of its complexity and multitude
38 of features, may provide an OS-circumventing attack vector, which can
39 only be dealt with by revoking (probably Microsoft) keys in UEFI
40 firmware, and re-signing only the necessary drivers with a custom key.
41 Compromising major player's certificates is a real possibility — e.g.,
42 see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft.
43
44 > What API?  The signing tool is public, and no, it doesn't add keys,
45 > that's up to the BIOS to do, not the userspace tool.
46
47 So the re-signing mentioned above must be done in a tedious manual
48 process? Or can some automatic tool be developed (not necessary
49 userspace, it can be an EFI app)?
50
51 --
52 Maxim Kammerer
53 Liberté Linux: http://dee.su/liberte