efi-boot-shim.git, branch 15.2

Fix incorrect allocation size for EV_EFI_BOOT_SERVICES_APPLICATION events

2020-10-15T23:38:52+00:00

sizeof(EFI_IMAGE_LOAD_EVENT) needs to represent the size of the header so we can add the actual device path size to it to compute the event. Signed-off-by: Peter Jones

hexdump.h: fix arithmetic error.

2020-10-15T23:17:35+00:00

When I modified the hexdumper to help debug MokListRT mirroring not working because of PcdMaxVolatileVariableSize being tiny, I inadvertently added something that is effectively: hexdump(..., char *buf, ..., int position) { unsigned long begin = (position % 16); unsigned long i; ... for (i = 0; i < begin; i++) { ... } ... } Unfortunately, in c if 0x8 is set in position, that means begin is 0xfffffffffffff8, because signed integer math is horrifying: include/hexdump.h:99:vhexdumpf() &data[offset]:0x9E77E6BC size-offset:0x14 include/hexdump.h:15:prepare_hex() position:0x9E77E6BC include/hexdump.h:17:prepare_hex() before:0xFFFFFFFFFFFFFFFC size:0x14 include/hexdump.h:19:prepare_hex() before:0xFFFFFFFFFFFFFFFC after:0x0 include/hexdump.h:21:prepare_hex() buf:0x000000009E77E2BC offset:0 &buf[offset]:0x000000009E77E2BC Woops. This could further have been prevented in /some/ cases by simply not preparing the hexdump buffer when "verbose" is disabled. This patch makes "pos" be unsigned in all cases, and also checks for verbose in vhexdumpf() and simply returns if it is 0. Signed-off-by: Peter Jones

Fix some mokmanager deletion paths

2020-10-15T23:17:35+00:00

This fixes several codepaths where MokList and MokListX are supposed to be deleted, but are not. It also adds debug logging to much of the deletion codepath.

Fix buffer overrun due DEFAULT_LOADER length miscalculation

2020-09-09T19:56:39+00:00

The DEFAULT_LOADER is a UCS-2 string and the StrLen() function returns the number of UCS-2 encoded characters in the string. But the allocated memory is in bytes, so only half of the needed memory to store it is allocated. This leads to a buffer overrun when the StrCpy() function attempts to copy the DEFAULT_LOADER to the allocated buffer. Fixes: 354bd9b1931 ("Actually check for errors from set_second_stage()") Reported-by: Stuart Hayes Signed-off-by: Javier Martinez Canillas

mirror_one_mok_variable(): round allocation up to a full page

2020-08-04T16:49:30+00:00

The code currently computes the size of the MoK variable in ram and rounds up to a full page, but then actually allocates the exact size, rather than the rounded up version. This should be completely safe, but the intent was to round up to at least the page size boundary, and to always guarantee rounding up /some/, to ensure extra 0-bytes at the end of the buffer. Signed-off-by: Peter Jones

Implement lennysz's suggestions for MokListRT

2020-07-26T02:14:08+00:00

Signed-off-by: Peter Jones

Also use a config table to mirror mok variables.

2020-07-26T02:14:08+00:00

Everything was going just fine until I made a vendor_db with 17kB of sha256 sums in it. And then the same source tree that had worked fine without that threw errors and failed all over the place. I wrote some code to diagnose the problem, and of course it was a failure in mirroring MokList to MokListRT. As Patrick noted in 741c61abba7, some systems have obnoxiously low amounts of variable storage available: mok.c:550:import_mok_state() BS+RT variable info: MaximumVariableStorageSize:0x000000000000DFE4 RemainingVariableStorageSize:0x000000000000D21C MaximumVariableSize:0x0000000000001FC4 The most annoying part is that on at least this edk2 build, SetVariable() /does actually appear to set the variable/, but it returns EFI_INVALID_PARAMETER. I'm not planning on relying on that behavior. So... yeah, the largest *volatile* (i.e. RAM only) variable this edk2 build will let you create is less than two pages. It's only got 7.9G free, so I guess it's feeling like space is a little tight. We're also not quite preserving that return code well enough for his workaround to work. New plan. We try to create variables the normal way, but we don't consider not having enough space to be fatal. In that case, we create an EFI_SECURITY_LIST with one sha256sum in it, with a value of all 0, and try to add that so we're sure there's /something/ there that's innocuous. On systems where the first SetVariable() / QueryVariableInfo() lied to us, the correct variable should be there, otherwise the one with the zero-hash will be. We then also build a config table to hold this info and install that. The config table is a packed array of this struct: struct mok_variable_config_entry { CHAR8 name[256]; UINT64 data_size; UINT8 data[]; }; There will be N+1 entries, and the last entry is all 0 for name and data_size. The total allocation size will always be a multiple of 4096. In the typical RHEL 7.9 case that means it'll be around 5 pages. It's installed with this guid: c451ed2b-9694-45d3-baba-ed9f8988a389 Anything that can go wrong will. Signed-off-by: Peter Jones Upstream: not yet, I don't want people to read this before Wednesday. Signed-off-by: Peter Jones

Improve debug output some

2020-07-26T02:14:08+00:00

Signed-off-by: Peter Jones Upstream: pr#213

Make openssl accept the right set of KU/EKUs

2020-07-24T02:22:04+00:00

Signed-off-by: Peter Jones Upstream: pr#211

Handle binaries with multiple signatures.

2020-07-24T02:22:04+00:00

This adds support for multiple signatures. It first tries validating the binary by hash, first against our dbx lists, then against our db lists. If it isn't allowed or rejected at that step, it continues to the normal routine of checking all the signatures. At this point it does *not* reject a binary just because a signature is by a cert on a dbx list, though that will override any db list that certificate is listed on. If at any point any assertion about the binary or signature list being well-formed fails, the binary is immediately rejected, though we do allow skipping over signatures which have an unsupported sig->Hdr.wCertificateType. Signed-off-by: Peter Jones Upstream: pr#210