<feed xmlns='http://www.w3.org/2005/Atom'>
<title>efi-boot-shim.git/include, branch 15.2</title>
<subtitle> (mirror of https://github.com/vyos/efi-boot-shim.git)
</subtitle>
<id>https://git.amelek.net/vyos/efi-boot-shim.git/atom?h=15.2</id>
<link rel='self' href='https://git.amelek.net/vyos/efi-boot-shim.git/atom?h=15.2'/>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/'/>
<updated>2020-10-15T23:38:52+00:00</updated>
<entry>
<title>Fix incorrect allocation size for EV_EFI_BOOT_SERVICES_APPLICATION events</title>
<updated>2020-10-15T23:38:52+00:00</updated>
<author>
<name>James Bottomley</name>
<email>James.Bottomley@HansenPartnership.com</email>
</author>
<published>2020-10-15T23:38:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=5ec906ac6ce4596664a6a7f1626895ebca9cd65e'/>
<id>urn:sha1:5ec906ac6ce4596664a6a7f1626895ebca9cd65e</id>
<content type='text'>
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 &lt;pjones@redhat.com&gt;
</content>
</entry>
<entry>
<title>hexdump.h: fix arithmetic error.</title>
<updated>2020-10-15T23:17:35+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2020-07-30T18:34:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=64a18c4ea6588147a8cc9c140c4cf344cb27e41d'/>
<id>urn:sha1:64a18c4ea6588147a8cc9c140c4cf344cb27e41d</id>
<content type='text'>
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 &lt; 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() &amp;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 &amp;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 &lt;pjones@redhat.com&gt;
</content>
</entry>
<entry>
<title>Implement lennysz's suggestions for MokListRT</title>
<updated>2020-07-26T02:14:08+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2020-07-26T02:13:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=65be350308783a8ef537246c8ad0545b4e6ad069'/>
<id>urn:sha1:65be350308783a8ef537246c8ad0545b4e6ad069</id>
<content type='text'>
Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
</content>
</entry>
<entry>
<title>Also use a config table to mirror mok variables.</title>
<updated>2020-07-26T02:14:08+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2020-07-24T02:09:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=fecc2dfb8e408526221091923d9345796b8e294e'/>
<id>urn:sha1:fecc2dfb8e408526221091923d9345796b8e294e</id>
<content type='text'>
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 &lt;pjones@redhat.com&gt;
Upstream: not yet, I don't want people to read this before Wednesday.
Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
</content>
</entry>
<entry>
<title>Improve debug output some</title>
<updated>2020-07-26T02:14:08+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2020-07-24T00:29:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=fc4368fed53837e00d303600d8b628cb0392b629'/>
<id>urn:sha1:fc4368fed53837e00d303600d8b628cb0392b629</id>
<content type='text'>
Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Upstream: pr#213
</content>
</entry>
<entry>
<title>Add support for vendor_db built-in shim authorized list.</title>
<updated>2020-07-24T02:22:04+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2020-07-23T16:36:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=dd3a5d71252a1f94e37f1a4c8841d253630b305a'/>
<id>urn:sha1:dd3a5d71252a1f94e37f1a4c8841d253630b305a</id>
<content type='text'>
Potential new signing strategies ( for example signing grub, fwupdate
and vmlinuz with separate certificates ) require shim to support a
vendor provided bundle of trusted certificates and hashes, which allows
shim to trust EFI binaries matching either certificate by signature or
hash in the vendor_db.  Functionality is similar to vendor_dbx.

This also improves the mirroring quite a bit.
Upstream: pr#206
</content>
</entry>
<entry>
<title>tpm: Include information about PE/COFF images in the TPM Event Log</title>
<updated>2020-07-24T00:53:24+00:00</updated>
<author>
<name>Javier Martinez Canillas</name>
<email>javierm@redhat.com</email>
</author>
<published>2020-02-18T11:03:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=0a8f7ade76ff3eede486027eaa638181e6bed3b8'/>
<id>urn:sha1:0a8f7ade76ff3eede486027eaa638181e6bed3b8</id>
<content type='text'>
The "TCG PC Client Specific Platform Firmware Profile Specification" says
that when measuring a PE/COFF image, the TCG_PCR_EVENT2 structure Event
field MUST contain a UEFI_IMAGE_LOAD_EVENT structure.

Currently an empty UEFI_IMAGE_LOAD_EVENT structure is passed so users only
have the hash of the PE/COFF image, but not information such the file path
of the binary.

Signed-off-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Upstream-commit-id: c252b9ee94c
</content>
</entry>
<entry>
<title>translate_slashes(): don't write to string literals</title>
<updated>2020-07-24T00:53:24+00:00</updated>
<author>
<name>Laszlo Ersek</name>
<email>lersek@redhat.com</email>
</author>
<published>2020-01-28T22:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=c6bedd5b83529925c3ec08f96a3bf61c81bff0ae'/>
<id>urn:sha1:c6bedd5b83529925c3ec08f96a3bf61c81bff0ae</id>
<content type='text'>
Currently, all three invocations of the translate_slashes() function may
lead to writes to the string literal that is #defined with the
DEFAULT_LOADER_CHAR macro. According to ISO C99 6.4.5p6, this is undefined
behavior ("If the program attempts to modify such an array, the behavior
is undefined").

This bug crashes shim on e.g. the 64-bit ArmVirtQemu platform ("Data
abort: Permission fault"), where the platform firmware maps the .text
section (which contains the string literal) read-only.

Modify translate_slashes() so that it copies and translates characters
from an input array of "char" to an output array of "CHAR8".

While at it, fix another bug. Before this patch, if translate_slashes()
ever encountered a double backslash (translating it to a single forward
slash), then the output would end up shorter than the input. However, the
output was not NUL-terminated in-place, therefore the original string
length (and according trailing garbage) would be preserved. After this
patch, the NUL-termination on contraction is automatic, as the output
array's contents are indeterminate when entering the function, and so we
must NUL-terminate it anyway.

Fixes: 8e9124227d18475d3bc634c33518963fc8db7c98
Fixes: e62b69a5b0b87c6df7a4fc23906134945309e927
Fixes: 3d79bcb2651b9eae809b975b3e03e2f96c067072
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1795654
Signed-off-by: Laszlo Ersek &lt;lersek@redhat.com&gt;
Upstream-commit-id: 9813e8bc8b3
</content>
</entry>
<entry>
<title>MokManager: console mode modification for hi-dpi screen devices</title>
<updated>2020-07-24T00:53:24+00:00</updated>
<author>
<name>Ivan Hu</name>
<email>ivan.hu@canonical.com</email>
</author>
<published>2019-05-10T09:50:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=55163bc82c5179adb109c3d8b982c2689d68b4c9'/>
<id>urn:sha1:55163bc82c5179adb109c3d8b982c2689d68b4c9</id>
<content type='text'>
There are lots of hi-dpi laptops nowadays, as doing mok enrollment, the font
is too small to see.
https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1822043

This patch checks if the resolution is larger than Full HD (1920x1080) and
current console output columns and rows is in a good mode. Then swith the
console output to a better mode.

Signed-off-by: Ivan Hu &lt;ivan.hu@canonical.com&gt;
Upstream-commit-id: cf05af6d899
</content>
</entry>
<entry>
<title>shim: Rework pause functions and add read_counter()</title>
<updated>2020-07-24T00:52:12+00:00</updated>
<author>
<name>Peter Jones</name>
<email>pjones@redhat.com</email>
</author>
<published>2018-10-23T22:17:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/efi-boot-shim.git/commit/?id=1b382ef850de5a6c59b192c146a0e8d898d2d961'/>
<id>urn:sha1:1b382ef850de5a6c59b192c146a0e8d898d2d961</id>
<content type='text'>
Signed-off-by: Peter Jones &lt;pjones@redhat.com&gt;
Upstream-commit-id: fc6b0bca84e
</content>
</entry>
</feed>
