public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Bill Paul <wpaul@windriver.com>
To: "edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>
Subject: UEFI Secure Technologies
Date: Fri, 3 Feb 2017 13:15:52 -0800	[thread overview]
Message-ID: <201702031315.52842.wpaul@windriver.com> (raw)

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
=============================================================================


             reply	other threads:[~2017-02-03 21:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03 21:15 Bill Paul [this message]
2017-02-03 22:29 ` UEFI Secure Technologies Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201702031315.52842.wpaul@windriver.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox