From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 115CD820C3 for ; Fri, 3 Feb 2017 14:29:17 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63CFA81F03; Fri, 3 Feb 2017 22:29:17 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-37.phx2.redhat.com [10.3.116.37]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v13MTG0l024981; Fri, 3 Feb 2017 17:29:16 -0500 To: Bill Paul References: <201702031315.52842.wpaul@windriver.com> From: Laszlo Ersek Cc: "edk2-devel@lists.01.org" Message-ID: Date: Fri, 3 Feb 2017 23:29:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <201702031315.52842.wpaul@windriver.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 03 Feb 2017 22:29:17 +0000 (UTC) Subject: Re: UEFI Secure Technologies X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 22:29:17 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 02/03/17 22:15, Bill Paul wrote: > This is not strictly an EDK development question, but it may be the right > audience to ask. The UEFI 2.5 specification introduced a section called Secure > Technologies, which includes the definition for an EFI_PKCS7_VERIFY_PROTOCOL > (among others). > > My question is: what are the odds of this protocol being available in a given > UEFI firmware build for a fielded system? > > The context for this question has to do with how secure boot would be handled > for OSes other than Windows. Obviously, once UEFI validates the BOOTxxx.EFI > loader image, the next step would be for the boot loader to validate the OS > image that comes after it, which requires the same kind of cryptographic > signature validation that the UEFI firmware performs on loader. But the > signature check is built into the BS->LoadImage() service and the firmware > only knows how to check signatures on Microsoft PE/COFF images (signed > according to the Microsoft Authenticode spec). > > I'm assuming that somehow the Microsoft loader takes advantage of the fact > that Windows executables (including the kernel and its DLLs) are also PE/COFF, > and it somehow loads those with BS->LoadImage() too. That's great, if you're > Microsoft. > > But if you're not Microsoft, you can't use this strategy, which means your > loader needs its own custom crypto code. > > In theory the presence of EFI_PKCS7_VERIFY_PROTOCOL would mitigate this, but > only on systems where the firmware includes it. > > My concern is that since Windows doesn't depend on it, the odds of this > protocol being included in a given build might be fairly slim. I'd like to > hear some other (hopefully better-informed) opinions on this matter. (Not overly well informed:) - In the "Linux ecosystem", each stage of the boot has its own dedicated crypto code, to my knowledge (shim, grub2, kernel (for signed kernel modules)). - Perhaps the next version of the spec should require that if a firmware supports Secure Boot, then it expose EFI_PKCS7_VERIFY_PROTOCOL too? (Just a random thought, not at all researched.) Anyway, for runtime verification of drivers, modules etc, the kernel will need its own crypto stuff. Laszlo