From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SgL5Q-0007Gr-LA for garchives@archives.gentoo.org; Sun, 17 Jun 2012 19:24:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 76386E049A; Sun, 17 Jun 2012 19:24:07 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 5658CE06FE for ; Sun, 17 Jun 2012 19:22:53 +0000 (UTC) Received: by obbup19 with SMTP id up19so2253413obb.40 for ; Sun, 17 Jun 2012 12:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dee.su; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=3cfGwKkxiPYLE7ItPI1TGQqa5eXu5vjLL3SIOnzm4wQ=; b=To0Yqh13JhQkjUA2L/waEpV2jF54/E4xHiBkFLpM4gdH/oPla8ZHmuPE4YEXuP9bbH rVYYQf91Inay8+Y80oY26J5hiQO8j2fgVn+jOyvNQEPAsW8kdn8SkiraF0mWulE7C/qb 9n4daqSVtMlaJkjCfl4kkE/9X8bHYLWvMG6Bk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=3cfGwKkxiPYLE7ItPI1TGQqa5eXu5vjLL3SIOnzm4wQ=; b=nREJb0cdIiR7VXlyz/pbvNM13TUthVxa2lJpaWk8C7YoqsVHx7xQFC8cB4btuhdxBP OIesMkRIEjtb/vGi4a1uBgZ4OjPFYky4zfjuaWBiKgVDiamDhcJse5lAoXN3CDclEm5p nKjjugha1tXfzIT58ONonb9Lhi+AygNCcMLXKM8YoMbTsmhWljS2dRdka3OyyYOXRmJv Dk40hyA2vvV70UmWnZH31fTsHeUoLNP5zRotCvlpyeBT9lm1KRLs5Btxm6kcEzyF9WTn fRgGaOQ1iaFAXA/TrQaQRn+LohljA4QMZ9Ck97b1hl9RGDsbeIKsVpWcNDbO6I9ObJAl LYug== Received: by 10.182.197.69 with SMTP id is5mr12975210obc.32.1339960972732; Sun, 17 Jun 2012 12:22:52 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.76.167.194 with HTTP; Sun, 17 Jun 2012 12:22:32 -0700 (PDT) In-Reply-To: <20120617170300.GC31617@kroah.com> References: <20120615042810.GA9480@kroah.com> <4FDAEB22.4010109@gmail.com> <4FDAF42E.9010304@binarywings.net> <20120615113248.GA22231@waltdnes.org> <20120617170300.GC31617@kroah.com> From: Maxim Kammerer Date: Sun, 17 Jun 2012 22:22:32 +0300 Message-ID: Subject: Re: [gentoo-dev] UEFI secure boot and Gentoo To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkilTri0RyQF5eNKXqggudBcTVzhCnF7V64oPD7TehDRk99VlwuwJiJGcJRIzXokOERqfKT X-Archives-Salt: a0022328-f56a-4c65-b54d-6ddf5691e76c X-Archives-Hash: 2cb3ea1979d4878ab43c6b51d2c65106 On Sun, Jun 17, 2012 at 8:03 PM, Greg KH wrote: > Huh? =A0No, why would a user need to resign the UEFI drivers? =A0Those > "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? =A0Please explain. I am thinking about a possibility where a =93rogue=94 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 =93representation=94. 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 =97 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 =97 e.g., see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-mo= les-inside-microsoft. > What API? =A0The 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)? --=20 Maxim Kammerer Libert=E9 Linux: http://dee.su/liberte