From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E7FE5820BD for ; Fri, 3 Feb 2017 13:14:40 -0800 (PST) Received: from huisne.wrs.com (huisne.wrs.com [147.11.217.26]) by mail.windriver.com (8.15.2/8.15.1) with ESMTP id v13LEemV022663 for ; Fri, 3 Feb 2017 13:14:40 -0800 (PST) Received: from ala-wpaul-lx1.wrs.com (ala-wpaul-lx1.corp.ad.wrs.com [147.11.157.242]) by huisne.wrs.com (8.9.1/8.9.1) with ESMTP id NAA27665 for ; Fri, 3 Feb 2017 13:14:40 -0800 (PST) From: Bill Paul Organization: Wind River Systems To: "edk2-devel@lists.01.org" Date: Fri, 3 Feb 2017 13:15:52 -0800 User-Agent: KMail/1.13.5 (Linux/2.6.32-28-generic; KDE/4.4.5; x86_64; ; ) MIME-Version: 1.0 Message-Id: <201702031315.52842.wpaul@windriver.com> Subject: 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 21:14:41 -0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wpaul@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin =============================================================================