Peter Jones [Mon, 10 Jun 2013 21:35:33 +0000 (17:35 -0400)]
Move embedded certificates to their own section.
With this change, the embedded certificate and dbx lists (vendor_cert,
vendor_cert_size, vendor_dbx, and vendor_dbx_size) wind up being in a
section named .vendor_cert, and so will look something like:
------
fenchurch:~/devel/github.com/shim$ objdump -h shim.efi
This simplifies a security audit, because it means that different
versions of shim with substantially the same code with different keys
will be more easily comperable, and therefore logic differences may be
more easily identified.
This also means that if there's a trusted build you want to use, you can
remove the certificates, implant new ones, and have it signed, and the
code sections won't change.
Peter Jones [Thu, 2 May 2013 18:58:44 +0000 (14:58 -0400)]
[fallback] Try to execute the first new boot option.
I'm told rebooting is sometimes unreliable when called here, and we'll
get bootx64.efi loaded anyway. I'll just assume that's true and try to
load the first option, since it's clearly what we'd prefer happens next.
Peter Jones [Tue, 30 Apr 2013 13:46:22 +0000 (09:46 -0400)]
Add a fallback loader for when shim is invoked as BOOTX64.EFI
If shim is invoked as \EFI\BOOT\BOOT*.EFI and a file exists named
\EFI\BOOT\FALLBACK.EFI, try it instead of our second stage. So don't
put fallback.efi on your install media in \EFI\BOOT, because that won't
do whatever it is you're hoping for, unless you're hoping not to start
the installer.
So here's the process for using this:
in /EFI/fedora/ (or whichever directory you happen to own), you put:
shim.efi
grub.efi
boot.csv - format is: shim.efi,Nice Label,cmdline arguments,comments
- filenames refer only to files in this directory, with no
leading characters such as L"./" or L"/EFI/fedora/"
- note that while this is CSV, the character encoding is
UCS-2
and if /EFI/BOOT/BOOTX64.EFI doesn't already exist, then in /EFI/BOOT:
shim.efi as BOOTX64.EFI
fallback.efi
The previous commit, 14d4b8e, caused shim failed to parse the name
of the 2nd stage loader in UEFI shell. Amend parsing of the name the
2nd stage loader to be compatible with UEFI shell.
Since Pause() doesn't clear the key from the input queue, the next
ReadKeyStroke reads the queued key instead of the new one. If the
user presses "Enter", MokManager exits directly without showing
the menu again.
This commit replaces the 2nd stage loader path with the first
argument in the Load Options and moves the rest arguments (if any)
to the Load Options for the 2nd stage loader.
For example, to make shim to load elilo.efi, just create a new
boot entry with efibootmgr:
Matthew Garrett [Mon, 26 Nov 2012 18:43:50 +0000 (13:43 -0500)]
Sign MokManager with a locally-generated key
shim needs to verify that MokManager hasn't been modified, but we want to
be able to support configurations where shim is shipped without a vendor
certificate. This patch adds support for generating a certificate at build
time, incorporating the public half into shim and signing MokManager with
the private half. It uses pesign and nss, but still requires openssl for
key generation. Anyone using sbsign will need to figure this out for
themselves.
Matthew Garrett [Thu, 1 Nov 2012 14:39:31 +0000 (10:39 -0400)]
Fix AuthenticodeVerify loop
Cert needs to be modified inside the Index loop, not outside it. This is unlikely to
ever trigger since there will typically only be one X509 certificate per
EFI_SIGNATURE_LIST, but fix it anyway.
Matthew Garrett [Wed, 24 Oct 2012 05:14:50 +0000 (01:14 -0400)]
Clean up password setting
Permit clearing of the password, and avoid a case where choosing not to set
a password would result in an error message on exit. Fix the same problem
with MokSB.
Matthew Garrett [Wed, 24 Oct 2012 04:10:29 +0000 (00:10 -0400)]
Boot unsigned binaries if we're not in secure mode
read_header would fail if the binary was unsigned, even if we weren't then
going to verify the signature. Move that check to the verify function
instead.
Peter Jones [Tue, 23 Oct 2012 15:47:41 +0000 (11:47 -0400)]
Support a vendor-specific DBX list.
In some rare corner cases, it's useful to add a blacklist of things that
were allowed by a copy of shim that was never signed by the UEFI signing
service. In these cases it's okay for them to go into a local dbx,
rather than taking up precious flash.
Matthew Garrett [Thu, 18 Oct 2012 21:43:53 +0000 (17:43 -0400)]
Add MOK password auth
Add support for setting an MOK password. The OS passes down a password hash.
MokManager then presents an option for setting a password. Selecting it
prompts the user for the same password again. If they match, the hash is
enrolled into a boot services variable and MokManager will prompt for the
password whenever it's started.
Matthew Garrett [Thu, 18 Oct 2012 21:41:52 +0000 (17:41 -0400)]
Add support for disabling signature verification
Provide a mechanism for a physically present end user to disable signature
verification. This is handled by the OS passing down a variable that
contains a UINT32 and a SHA256 hash. If this variable is present, MokManager
prompts the user to choose whether to enable or disable signature validation
(depending on the value of the UINT32). They are then asked to type the
passphrase that matches the hash. This then saves a boot services variable
which is checked by shim, and if set will skip verification of signatures.
The size of the DevPath string array was not sufficient to append
the volume label. This patch extends the size for the label and
re-enables the menu freeing.
Matthew Garrett [Fri, 12 Oct 2012 23:55:20 +0000 (19:55 -0400)]
Remove LoadImage/StartImage support
Some systems will show an error dialog if LoadImage() returned
EFI_ACCESS_DENIED, which then requires physical user interaction to skip.
Let's just remove the LoadImage/StartImage code, since the built-in code
is theoretically equivalent.
Matthew Garrett [Fri, 12 Oct 2012 23:55:20 +0000 (19:55 -0400)]
Switch to using db format for MokList and MokNew
Using the same format as the UEFI key databases makes it easier for the
kernel to parse and extract keys from MOK, and also permits MOK to contain
multiple key or hash types. Additionally, add support for enrolling hashes.