On Sun, Jun 17, 2012 at 8:03 PM, Greg KH <gre...@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
