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