I'm still having some trouble with the offsetof() definition, so just
nerf it to what stddef.h would say anyway.
Signed-off-by: Peter Jones <pjones@redhat.com>
Disable DES completely since it's already old and insecure.
This makes MokManager not support the DES based password hash but
probably no one is using it.
Signed-off-by: Gary Lin <glin@suse.com>
- Declare some functions in the proper headers
+ We missed them for a long time...
- Cast offsetof to UINTN
+ The original casting triggers the gcc warning since int can not
present the offset for the 64bit machines.
- Cast the "char" array to "CHAR8 *" to avoid the gcc warnings
- Implement atoi correctly
Signed-off-by: Gary Lin <glin@suse.com>
strcmp() and strcasecmp() are widely used in openssl. Implement those
two functions to eliminate the gcc warnings and the potential crash.
Signed-off-by: Gary Lin <glin@suse.com>
The changes in the openssl headers cause the inclusion of
CrtLibSupport.h eariler than the inclusion of stddef.h, so "offsetof"
was defined twice and this caused the followling build error:
In file included from Cryptlib/Include/openssl/buffer.h:23:0,
from Cryptlib/Include/openssl/x509.h:22,
from shim.c:56:
/usr/lib64/gcc/x86_64-suse-linux/6/include/stddef.h:417:0: error: "offsetof" redefined [-Werror]
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
In file included from Cryptlib/Include/limits.h:15:0,
from Cryptlib/Include/openssl/ossl_typ.h:13,
from Cryptlib/Include/openssl/x509.h:20,
from shim.c:56:
Cryptlib/Include/CrtLibSupport.h:192:0: note: this is the location of the previous definition
#define offsetof(type, member) ( (int) & ((type*)0) -> member )
We can lower the priority of the gcc include path or just remove the
path, but this might cause problem since the path was introduced on
purpose(*). Instead, including stddef.h first is more feasible.
(*) d51739a416
Signed-off-by: Gary Lin <glin@suse.com>
OpenSSL changes quite a bit of the key validation, and most of the keys
I can find in the wild aren't marked as trusted by the new checker.
Intel noticed this too: https://github.com/vathpela/edk2/commit/f536d7c3ed
but instead of fixing the compatibility error, they switched their test
data to match the bug.
So that's pretty broken.
For now, I'm reverting OpenSSL 1.1.0e, because we need those certs in
the wild to work.
This reverts commit 513cbe2aea.
This reverts commit e9cc33d6f2.
This reverts commit 80d49f758e.
This reverts commit 9bc647e2b2.
This reverts commit ae75df6232.
This reverts commit e883479f35.
This reverts commit 97469449fd.
This reverts commit e39692647f.
This reverts commit 0f3dfc01e2.
This reverts commit 4da6ac8195.
This reverts commit d064bd7eef.
This reverts commit 9bc86cfd6f.
This reverts commit ab9a05a10f.
Signed-off-by: Peter Jones <pjones@redhat.com>
Rather than looping once through the possible actions (MokNew, MokDel, etc.),
revise the logic so that instead of rebooting immediately we get back to the
main menu setting a flag to replace "Continue booting" with a proper reboot.
Getting back to the menu means we can go make other changes before rebooting.
For instance, you might want to enable validation, but beforehand you also
need to enroll a MOK. You can already do so from userland; except the requests
were cleared as soon as one of them was processed.
This involves some extra cleanup of the states to avoid running the same
request more than once, removing the option from the menu once it's done, and
changing prompting functions to return an EFI_STATUS so we can better track
whether the process has succeeded.
Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
If the boot option recorded in csv is not in a media device path, the
corresponding full device path will be referred for creating the boot
variable.
However, the current code logic always frees the full device path
(full_device_path) and the media device path (dp) separately. In order
to resolve this issue, always check whether dp equals to full_device_path
before freeing dp.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
Since booting the entry with fallback in the stack of things that got
measured will result in all the wrong PCR values, in the cases where TPM
is present and enabled, use ->Reset() instead of loading the Boot####
variable and executing its target.
Signed-off-by: Peter Jones <pjones@redhat.com>
Even if errors occurred, always try to measure all of our Mok entries.
This way we won't fail on e.g. MokList not being set.
Signed-off-by: Peter Jones <pjones@redhat.com>
We're currently measuring the raw second stage loader into PCR 9, but
we're closer to spec if we measure the semi-parsed PE into PCR 4. The
hash that's logged is the same as the hash used for the Authenticode
validation, so refactor shim.c a little to separate out the hash
generation.
It's desirable to be able to use PCR 7 for all TPM policy on Secure Boot
systems, but right now Shim doesn't record any information about its
configuration or the signature used to launch the second stage loader. Add
support for that.
Rob Clark noticed while, implementing a UEFI like backend on u-boot,
that if a File Handle actually returns a meaningful device path from
DevicePathFromHandle(), we wind up with a horribly wrong device path in
the boot variable. He's right, normal UEFI doesn't return that, which
means FileDevicePath() in our code currently does nothing at all.
Instead of all that, pass in the device's handle, and it'll do what
we're doing after the fact there.
Here's the log from a current run:
FS0:\> \efi\BOOT\BOOTX64.EFI
System BootOrder not found. Initializing defaults.
find_boot_options:778:Found directory named "fedora"
try_boot_csv:532:Found file "\EFI\fedora\BOOT.CSV"
try_boot_csv:544:File looks like:
?shim.efi,Fedora,,This is the boot entry for Fedora
populate_stanza:495:CSV data: "shim.efi,Fedora,,This is the boot entry for Fedora"
populate_stanza:501:filename: "shim.efi"
populate_stanza:508:label: "Fedora"
populate_stanza:514:arguments: ""
add_to_boot_list:430:file DP: PciRoot(0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi
FindSubDevicePath:78:input device path: "PciRoot(0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi"
FindSubDevicePath:86:sub-path (4,1): "HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi"
add_to_boot_list:452:04 01 2A 00 01 00 00 00 00 08 00 00 00 00 00 00
add_to_boot_list:452:00 40 06 00 00 00 00 00 2A 27 84 65 B9 D7 2A 44
add_to_boot_list:452:B8 A4 19 B5 EC 45 66 F4 02 02 04 04 2E 00 5C 00
add_to_boot_list:452:45 00 46 00 49 00 5C 00 66 00 65 00 64 00 6F 00
add_to_boot_list:452:72 00 61 00 5C 00 73 00 68 00 69 00 6D 00 2E 00
add_to_boot_list:452:65 00 66 00 69 00 00 00 7F FF 04 00
add_to_boot_list:459:device path: "HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi"
Creating boot entry "Boot0000" with label "Fedora" for file "\EFI\fedora\shim.efi"
AddOption - Boot0000, then CurrentCount = 0x00000008
update_boot_order:390:nbootorder: 7
BootOrder: 0000 0002 0001 0003 0005 0006 0004
Signed-off-by: Peter Jones <pjones@redhat.com>
This lets you do:
mkdir build-x64 build-ia32
cd build-x64
make TOPDIR=.. -f ../Makefile
cd ../build-ia32
setarch i686 -B make ARCH=ia32 TOPDIR=.. -f ../Makefile
And not worry about generated sources and headers mixing and matching.
Signed-off-by: Peter Jones <pjones@redhat.com>
BOOT.CSV should be placed in fedora directory in order to locate the base
directory of files recorded in $FILENAME column.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
When dir->Read() says bs=0, we shouldn't try to allocate a buffer and
read into it. On edk2 this works because there's an implicit (possibly
accidental) minimum size of one pool list entry that can be allocated,
so you wind up getting (I think) 8 bytes.
When Rob Clark tried to run this under uboot's emulated UEFI
environment, dir->Read() returned 0 and when we passed that to
AllocateZeroPool() less good things happened.
So just check for that case and exit appropriately.
Signed-off-by: Peter Jones <pjones@redhat.com>
The TCG EFI Protocol Specification for family "2.0" mentions that not all
TPM2 chips may support the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 (crypto agile)
log format. So instead of always use this log format, the GetCapability()
function should be used to determine which format is supported by the TPM.
For example, the Intel PTT firmware based TPM found in Lenovo Thinkapd X1
Carbon (4th gen), only supports SHA-1 (EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2)
log format. So a call to GetEventLog() using the crypto agile format was
returning EFI_INVALID_PARAMETER, making tpm_log_event() function to fail.
This was preventing shim to correctly measure the second stage bootloader:
$ tpm2_listpcrs -L 0x04:9
Bank/Algorithm: TPM_ALG_SHA1(0x0004)
PCR_09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After passing a supported log format to GetEventLog(), it succeeds and so
shim is able to call the HashLogExtendEvent() EFI function correctly:
$ tpm2_listpcrs -L 0x04:9
Bank/Algorithm: TPM_ALG_SHA1(0x0004)
PCR_09: 07 5a 7e d3 75 64 ad 91 1a 34 17 17 c2 34 10 2b 58 5b de b7
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The EFI_TCG2_PROTOCOL.GetCapability() function is used to learn if a TPM2
chip is present. But the protocol capability information is also needed
for other reasons, for example to determine what event log formats are
supported by the firmware.
Take out the GetCapability() call from the tpm2_present() logic and reduce
that function to just checking if a TPM2 chip is available or not, so the
capabilities can later be used to determine the supported TPM log formats.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
When measuring data into the TPM and generating events logs, the event
type is set to EV_IPL (0xd), and for TPM1.2 the algorithm will always
be set to SHA-1 (0x4).
So, add some macro-defined constants for these instead of having them
as magic numbers to make the code more readable.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
EFI_NOT_FOUND will be returned when creating MokListRT if vendor cert is
empty. This is harmless, meaningless and skippable.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
Since 87060b2fc effectively means signing with signtool.exe simply does
not work correctly, and that's sort of the biggest goal for shim, make
this version 12.
Signed-off-by: Peter Jones <pjones@redhat.com>
