Matthew Garrett [Tue, 11 Dec 2018 23:25:44 +0000 (15:25 -0800)]
Remove call to TPM2 get_event_log()
Calling the TPM2 get_event_log causes the firmware to start logging
events to the final events table, but implementations may also continue
logging to the boot services event log. Any OS that wishes to
reconstruct the full PCR state must already look at both the final
events log and the boot services event log, so if this call is made
anywhere other than immediately before ExitBootServices() then the OS
must deduplicate events that occur in both, complicating things
immensely.
Linux already has support for copying up the boot services event log
across the ExitBootServices() boundary, so there's no reason to make
this call. Remove it.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Upstream-commit-id: fd7c3bd920b
Gary Lin [Wed, 19 Dec 2018 03:27:42 +0000 (11:27 +0800)]
shim: only include shim_cert.h in shim.c
The shim_cert array was declared as a static array, and every user of
shim_cert.h would create a shim_cert array for its own and grow the file
size. To remove the unnecessary duplicate shim_cert arrays, this commit
declares shim_cert in shim.c while other users still can access the
array through the external variables: build_cert and build_cert_size.
Signed-off-by: Gary Lin <glin@suse.com>
Upstream-commit-id: 4e2d62f0f4e
Gary Lin [Wed, 21 Nov 2018 04:47:43 +0000 (12:47 +0800)]
mok: fix the mirroring of RT variables
When there is no key in MokList, import_mok_state() just skipped MokList
even though it should always mirror the vendor cert. Besides, the faulty
check of 'present' and 'addend' invalidates the mirroring of MokListXRT,
MokSBStateRT, and MokIgnoreDB.
https://github.com/rhboot/shim/issues/154
Signed-off-by: Gary Lin <glin@suse.com>
Upstream-commit-id: 4b27ae034ba
Without this, if a Mok variable doesn't exist in Boot Services, it will also
not be copied to Runtime, even if we have data to be added to it (vendor cert).
This patch makes sure that if we have extra data to append, we still mirror
the variable.
Signed-off-by: Patrick Uiterwijk <patrick@puiterwijk.org>
Upstream-commit-id: 9ab0d796bdc
Luca Boccassi [Mon, 14 Jan 2019 19:29:34 +0000 (19:29 +0000)]
Makefile: do not run git on clean if there's no .git directory
When building in minimal chroot on build workers, like in Debian (where
make clean is called at the beginning of the build process), git will
not be available. Skip the git clean.
Maran Wilson [Tue, 7 Aug 2018 22:32:29 +0000 (15:32 -0700)]
Fix for "Section 0 has negative size" error when loading fbaa64.efi
The current code is incorrectly failing to load the fbaa64.efi image found
in Arm servers even though the UEFI shell code is able to properly load
and execute the same image.
The problem is due to the presence of a section header that has zero size
and address and marked "discardable" in the fbaa64.efi image.
Although there is already a check further down in the code to look for
the discardable bit and skip further verification checks if set, we never
get to that point due to the "end < base" check at the start of the loop.
Here is a dump of the fbaa64.efi image as compiled on an Arm machine
from the latest code in this repo:
% # First I used hexedit to change header byte from 'AA' to '86'
% # so that objdump was able to correctly parse the file:
% objdump -x -m aarch64 fbaa64.efi
Signed-off-by: Maran Wilson <maran.wilson@oracle.com> Reviewed-by: Aaron Young <aaron.young@oracle.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com>
Upstream-commit-id: 6df7a8f5609
shim: Prevent shim to set itself as a second stage loader
When shim is invoked from a relative path (e.g: from the UEFI shell), the
Loaded Image handle LoadOptions can be set to the binary relative path.
But the is_our_path() function only checks if LoadOptions is set to the
absolute path of shim to ignore it. So if a relative path is there, shim
would set itself as the secondary loader and invoke itself in a loop.
To prevent that, use the path in LoadOptions to calculate the absolute
path and compare it with the one in the Loader Image handle FilePath.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maran Wilson maran.wilson@oracle.com Tested-by: Maran Wilson maran.wilson@oracle.com
Upstream-commit-id: e563bc3dcd1
shim: Properly generate absolute paths from relative image paths
The generate_path_from_image_path() doesn't properly handle the case when
shim is invoked using a relative path (e.g: from the EFI shell). In that
function, always the last component is stripped from absolute file path
to calculate the dirname, and this is concatenated with the image path.
But if the path is a relative one, the function will wrongly concatenate
the dirname with the relative image path, i.e:
Shell> FS0:
FS0:\> cd EFI
FS0:\EFI\> BOOT\BOOTX64.EFI
Failed to open \EFI\BOOT\BOOT\BOOTX64.EFI - Not found
Failed to load image \EFI\BOOT\BOOT\BOOTX64.EFI: Not found
start_image() returned Not found
Calculate the image path basename and concatenate that with the dirname.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maran Wilson maran.wilson@oracle.com Tested-by: Maran Wilson maran.wilson@oracle.com
Upstream-commit-id: a625fa5096c
TanMing [Tue, 21 Aug 2018 06:25:52 +0000 (02:25 -0400)]
Fix the compile error of mkdir wrong directory.
In Ubuntu 14.04, the following code in old Makefile:
mkdir -p Cryptlib/{Hash,Hmac,Cipher,Rand,Pk,Pem,SysCall}
will create a directory named "{Hash,Hmac,Cipher,Rand,Pk,Pem,SysCall}".
Signed-off-by: Ming Tan <ming.tan@intel.com>
Upstream-commit-id: 39b83455d68
Gary Lin [Fri, 11 May 2018 08:59:03 +0000 (16:59 +0800)]
MokManager: Stop using EFI_VARIABLE_APPEND_WRITE
When writing MokList with EFI_VARIABLE_APPEND_WRITE, some HP laptops
may just return EFI_SUCCESS without writing the content into the flash,
so we have no way to detect if MokList is updated or not. Now we always
read MokList first and write it back with the new content.
https://github.com/rhboot/shim/issues/105
Signed-off-by: Gary Lin <glin@suse.com>
Upstream-commit-id: f442c8424b4
Gary Lin [Mon, 28 May 2018 09:24:30 +0000 (17:24 +0800)]
httpboot: print more messages when it fails to set IP
We previously only print the return status and it may not be clear
enough in some situations. Print the IP address and the gateway to help
the user to identify the possible errors.
Signed-off-by: Gary Lin <glin@suse.com>
Upstream-commit-id: 3abe94516c7
Let MokManager follow a MokTimeout var for timeout length for the prompt
This timeout can have the values [-1,0..0x7fff]; where -1 means "no timeout",
with MokManager going directly to the menu, and is capped to 0x7fff to avoid
unecessary long timeouts. The default remains 10, which will be used whenever
the MokTimeout variable isn't set.
Peter Jones [Thu, 12 Apr 2018 17:24:48 +0000 (13:24 -0400)]
Makefiles: ensure -m32 gets propogated to our gcc parameter queries
'gcc -print-file-name=include' and 'gcc -print-libgcc-file-name' both
need -m32 when we're building 32-on-64 on some distros, so ensure that
gets propogated correctly.
Signed-off-by: Peter Jones <pjones@redhat.com>
Upstream-commit-id: 104d6e54ac7
Peter Jones [Fri, 23 Mar 2018 17:54:53 +0000 (13:54 -0400)]
Revert "Allow shim to handle multiple trusted certificates"
This was merged before it was really ready - verify_trusted_cert needs
to check each certificate against vendor_dbx, "dbx", and "MokListX", or
else it can enable a blacklisted certificate accidentally.
Everything Hans said was correct. But StrnCat() is in gnu-efi 3.0.8,
and using just StrCpy() here confuses coverity. I'd rather have a CI
page that's not completely full of chaff, but a little bit of redundancy
in the code.
Peter Jones [Thu, 15 Mar 2018 15:13:25 +0000 (11:13 -0400)]
Work around clang bugs for scan-build.
I don't think the x86 binaries clang builds will actually work unless
they just infer -maccumulate-outgoing-args from __attribute__((__ms_abi__),
but it's nice to have the analyzer working.
Michael Brown [Fri, 9 Mar 2018 17:51:09 +0000 (17:51 +0000)]
Allow memory allocated by handle_image() to be freed
There is currently no way for a caller of handle_image() to free the
memory allocated to hold the relocated executable. Fix by adding the
allocated memory address and number of pages as returned parameters
from handle_image().
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Michael Brown [Mon, 12 Mar 2018 20:31:37 +0000 (20:31 +0000)]
Do not modify original image
relocate_coff() currently modifies the PE header within the raw data.
This appears to be unnecessary, and causes a verification failure if a
second attempt is made to verify the same data buffer.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Hans de Goede [Tue, 13 Mar 2018 08:26:25 +0000 (09:26 +0100)]
MokManager: stop using StrnCat
StrnCat is not available in gnu-efi-3.0.5 (I did not check if it does
actually exists in 3.0.6). Moreover using strcat on a buffer where we've
just done: "buf[0] = '\0'" is a bit silly, we might as well drop the 0
termination and just use strcpy.
It seems there also is no StrnCpy in gnu-efi-3.0.5, but we are passing in
a pointer to the end of file_name minus 4, so strcpy will consume only
4 bytes anyways and there is no need for the "n".
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Tue, 13 Mar 2018 07:54:26 +0000 (08:54 +0100)]
console: Fix indentation
The manual merge of the "console: Do not set EFI console to textmode until
something is printed" patch has lead to a bunch of tabs being replaced
with 7 spaces. This commit fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 12 Mar 2018 16:14:58 +0000 (17:14 +0100)]
console: Do not set EFI console to textmode until something is printed
Remove the setup_console(1) calls from shim and instead make lib/console.c
make that call when necessary. This avoids shim forcing the EFI console to
switch to text-mode if nothing is printed.
This commit also modifies MokManager to work the same way for consistency,
even though MokManager will always print something.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Hans de Goede [Mon, 12 Mar 2018 15:03:38 +0000 (16:03 +0100)]
console: Add console_print and console_print_at helpers
This is a preparation commit for removing the setup_console(1) calls from
MokManager and shim so that we don't force the EFI console to switch to
text-mode.
This commit replaces all direct calls to Print / PrintAt with calls to
the new helpers (no functional changes) so that we can delay calling
setup_console(1) till the first Print call in a follow-up patch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tamas K Lengyel [Sun, 31 Dec 2017 18:03:26 +0000 (11:03 -0700)]
shim: Don't overwrite EFI_LOADED_IMAGE's LoadOptions when not needed
When the firmware is using EFI_LOAD_OPTION to specify options for the secondary
loader, the shim will properly detect that and return in set_second_stage. Later
howerer in handle_image EFI_LOADED_IMAGE is being overwritten with load_option
irrespective of the fact that load_option was never set. This effectively
prevents the EFI_LOAD_OPTION from reaching the secondary loader.
Only overwrite EFI_LOADED_IMAGE's LoadOptions when load_option is not NULL
solves the problem.
Signed-off-by: Tamas K Lengyel <lengyelt@ainfosec.com>
Peter Jones [Wed, 18 Oct 2017 21:33:09 +0000 (17:33 -0400)]
shim: Make our variable validation and mirroring table driven.
This makes it so shim's idea of Mok variables all resides in one table
of data, and we don't need a bunch of nearly identical ad-hoc functions
to handle each of them.
Peter Jones [Thu, 19 Oct 2017 17:53:56 +0000 (13:53 -0400)]
shim: generate_hash(): make clang-analyzer not get confused.
clang-analyzer thinks that because we're not checking for NULL from
ImageAddress() it can be NULL, but doesn't realize we've already checked
that value once before.
Peter Jones [Thu, 28 Sep 2017 18:11:51 +0000 (14:11 -0400)]
Don't use uefi_call_wrapper(), ever.
I'm pretty done with typing uefi_call_wrapper() and counting arguments
every time. Instead, just make the compiler error if we don't have
ms_abi. Also, make it so nothing can use uefi_call_wrapper() directly.
Peter Jones [Thu, 28 Sep 2017 13:44:46 +0000 (09:44 -0400)]
shim: relocate_coff(): get rid of "FixupData" stuff
"FixupData" in the edk2 tree is a log of the relocations that happened,
which is allocated by the "client" calling relocate, and written into
while it does relocations. Since we never allocate that log anywhere,
FixupData is always NULL, and so covscan says:
318 case EFI_IMAGE_REL_BASED_HIGH:
319 Fixup16 = (UINT16 *) Fixup;
320 *Fixup16 = (UINT16) (*Fixup16 + ((UINT16) ((UINT32) Adjust >> 16)));
null: At condition FixupData != NULL, the value of FixupData must be
NULL. dead_error_condition: The condition FixupData != NULL cannot
be true.
321 if (FixupData != NULL) {
CID 182859 (#1 of 4): Logically dead code (DEADCODE)dead_error_begin:
Execution cannot reach this statement: *((UINT16 *)FixupData) =
*F....
322 *(UINT16 *) FixupData = *Fixup16;
323 FixupData = FixupData + sizeof (UINT16);
324 }
325 break;
And it's right; all four occurrances are deadcode that never do anything
but confuse the reader.
Peter Jones [Wed, 27 Sep 2017 20:23:14 +0000 (16:23 -0400)]
shim: ensure generate_hash() never operates on a negative (signed) number.
Covscan noticed:
746static EFI_STATUS generate_hash (char *data, unsigned int datasize_in,
747 PE_COFF_LOADER_IMAGE_CONTEXT *context,
748 UINT8 *sha256hash, UINT8 *sha1hash)
749
750{
...
764
CID 182849 (#1 of 1): Unsigned compared against 0
(NO_EFFECT)unsigned_compare: This less-than-zero comparison of an
unsigned value is never true. datasize_in < 0U.
765 if (datasize_in < 0) {
766 perror(L"Invalid data size\n");
767 return EFI_INVALID_PARAMETER;
768 }
And I guess that's a fair point, but some of the callers take the size
as a signed integer. So we should be handling that on all the input
cases instead of getting that far.
Because it doesn't know that when bs==0, fh2->Read() will return
EFI_BUFFER_TOO_SMALL and set bs to the size we need to allocate, so the
allocation path is always taken. Instead, handle our exit/error paths
directly there, and make the allocation path nonconditional.
Peter Jones [Wed, 27 Sep 2017 17:15:13 +0000 (13:15 -0400)]
fallback: read_file(): limit how big the file can be and still be valid
Covscan says:
146 UINTN len = 0;
147 CHAR16 *b = NULL;
2. tainted_data_argument: Calling function get_file_size taints argument len.
148 rc = get_file_size(fh2, &len);
3. Condition (INTN)rc < 0, taking false branch.
149 if (EFI_ERROR(rc)) {
150 uefi_call_wrapper(fh2->Close, 1, fh2);
151 return rc;
152 }
153
4. overflow_assign: Assigning overflowed or truncated value (or a value computed from an overflowed or a truncated value) to b.
8. overflow: Add operation overflows on operands len and 2UL. Example value for operand: len = 18446744073709551614.
154 b = AllocateZeroPool(len + 2);
Technically we can't handle a file larger than 0xfffffffffffffffd (on
x86_64) because when we try to allocate the buffer to hold it with a
trailing UCS-2 NUL we overflow to 0. Also our filesystem can't hold a
file bigger than 4GB... So this is probably actually broken on 32-bit
platforms.
This patch limits it to some handy amount like 1024 * PAGE_SIZE, aka
4MB.
Note that this doesn't appear to be exploitable (at least on edk2-based
firmwares), because AllocateZeroPool() has a minimum granularity of 1
page, so even if you overflow it with a 4GB file, we'll get 1 page out
of it and then try to read 1 byte into it, and then it's just going to
be a parse error on the CSV. Even if we error on the sentinal UCS-2 NUL
we put at the end, it'll still be inside of the zeroed page, and it still
won't fault or overwrite any meaningful data.
Peter Jones [Wed, 27 Sep 2017 17:05:16 +0000 (13:05 -0400)]
fallback: handle buffer allocations for fh->GetInfo() prettier.
At all the places we use fh->GetInfo, covscan can't tell that
fh->GetInfo() will return EFI_BUFFER_TOO_SMALL and we'll allocate on the
first try.
If we just explicitly check for "buffer == NULL" as well, covscan
believes we're doing work we don't need to (which is true!)
So instead, put an rc test to return error for everything else there, so
the allocation isn't in a conditional.
Yet another stupid one, but it's easier to nerf it this way than write
the false-positive rule, and it also hardens against incorrect UEFI
implementations (though we've not seen any yet with the problem this
avoids).
Peter Jones [Wed, 18 Oct 2017 21:33:34 +0000 (17:33 -0400)]
MokManager: Fix a conditional on an uninitialized value in one error path.
clang-analyzer says:
MokManager.c:1431:6: warning: Branch condition evaluates to a garbage value
if (mok)
^~~
MokManager.c:1433:6: warning: Branch condition evaluates to a garbage value
if (del_key)
^~~~~~~
And it's right; if we take the first error exit in the function, those
never get initialized. This patch sets them to NULL to begin with.
This guarantees it won't be in the list the next time through the loop.
This adds tests for NULLness before mok_sb_prompt(), just to make it
more clear to covscan what's going on.
Also do the same thing for all of:
MOK_CHANGE_SB
MOK_SET_PW
MOK_CHANGE_DB
MOK_ENROLL_MOKX
MOK_DELETE_MOKX
I also Lindent-ed everything I had to touch.
Three other minor errors are also fixed:
1) the loop in enter_mok_menu() leaked the menu allocations each time
through the loop
2) mok_sb_prompt(), mok_pw_prompt(), and mok_db_prompt() all call
FreePool() on their respective variables (MokSB, etc), and
check_mok_request() also calls FreePool() on these. This sounds
horrible, but it turns out it's not an issue, because they only free
them in their EFI_SUCCESS paths, and enter_mok_menu() resets the
system if any of the mok_XX_prompt() calls actually returned
EFI_SUCCESS, so we never get back to check_mok_request() for it to do
its FreePool() calls.
3) the loop in enter_mok_menu() winds up introducing a double free in
the call to free_menu(), but we also can't hit this bug, because all
the exit paths from the loop are "goto out" (or return error) rather
than actually exiting on the loop conditional.
Peter Jones [Wed, 27 Sep 2017 14:17:45 +0000 (10:17 -0400)]
MokManager: check_der_suffix(): use StrnCat() on our suffix checker.
We know it's legit already because we computed the pointer from the end,
but covscan gets confused, and we have StrnCat, so we should just use it
anyway.
And it can't figure out that the first GetVariable() call will, in fact,
always return EFI_BUFFER_TOO_SMALL, and that AllocateZeroPool() will
then *correctly* clobber the two variables we never assigned the value
from. It also then believes that efi_status might have been returned
/without/ being an error, and thinks that means we'll use the
uninitialized pointer.
This won't happen, but hey, let's make the code better express to the
checker what is intended.
Peter Jones [Wed, 27 Sep 2017 17:45:21 +0000 (13:45 -0400)]
lib: simple_file_selector(): simplify the error path to confuse covscan less.
Because they don't believe code should be defensive against future
changes, covscan believes:
520 out_free:
521 FreePool(dmp);
CID 182824 (#1 of 1): Dereference before null check
(REVERSE_INULL)check_after_deref: Null-checking entries suggests that
it may be null, but it has already been dereferenced on all paths
leading to the check.
522 if (entries) {
523 free_entries(entries, count);
524 FreePool(entries);
525 }
526 out_free_name:
527 FreePool(name);
528}
Which is technically correct, but still kind of dumb. So this patch
combines the two error out paths into just being out_free, so that the
first path there is before entries is allocated. (It also initializes
dmp to NULL and checks that before freeing it.)