dmidecode fails when booted with 1f123ac2359cd923e9144f944a4bddf597fddbb5

[jyong2]

When booted with shim, dmidecode fails to run:

# dmidecode -t baseboard
# dmidecode 3.2
# SMBIOS entry point at 0x748cd000
Found SMBIOS entry point in EFI, reading table from /dev/mem.
# No SMBIOS nor DMI entry point found, sorry.

Any ideas about this?

Edit: formatting

[jyong2]

Bisect seems to be suggesting fecc2df, tested on qemu 5.1.0.

[jsetje]

With secure boot enabled, lockdown prevents reads from /dev/mem. Newer dmidecode should be using sysfs instead.

Can you help us establish if you're seeing this change in behavior with or without secure boot enabled?

If you're seeing it with secure boot enabled, then the /dev/mem failure is expected and prior to that fix your kernel was failing to enforce lockdown.

If you're seeing it with secure boot disabled, then something else may have changed, and we should look into this further.

[jyong2]

dmidecode does use sysfs when possible, it works fine with the older shim, but the dmi tables entries are missing in the newer shim, causing it to fallback to /dev/mem. This happens regardless of secureboot or not.

I should also mention I am using ovmf edk2-stable201911 as part of Yocto Project.

[jyong2]

As of 018b74d commit, I am still getting errors:

root@intel-corei7-64:~# dmidecode -t baseboard
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Wrong DMI structures length: 383 bytes announced, only 16 bytes available.
Invalid entry length (0). DMI table is broken! Stop.

[jyong2]

Still same for 39b96c0

root@intel-corei7-64:~# dmidecode
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
9 structures occupying 383 bytes.
Table at 0x1FBCF000.

Wrong DMI structures length: 383 bytes announced, only 16 bytes available.
Invalid entry length (0). DMI table is broken! Stop.

root@intel-corei7-64:~# dmidecode -t baseboard
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Wrong DMI structures length: 383 bytes announced, only 16 bytes available.
Invalid entry length (0). DMI table is broken! Stop.

[jyong2]

7defee6 seems to be working, very strange. It might have something to do with switch to the gitsubmodule copy of gnu-efi.

[jyong2]

Issue seems to be happening sporadically while on real hardware, I'm not sure what else is happening.

[jyong2]

Found a likely buffer overflow in import_mok_state() introduced in fecc2df:

for (i = 0; mok_state_variables[i].name != NULL; i++) {
..
		if (v->data && v->data_size) {
			config_sz += v->data_size;
			config_sz += sizeof(config_template);
		}
}
...
gBS->AllocatePages
...
for (i = 0; p && mok_state_variables[i].name != NULL; i++) {
...
p += sizeof(config_template);
p += v->data_size;

if (p) {
  ...
  CopyMem(p, &config_template, sizeof(config_template));
  ...
}

There is an extra sizeof(config_template) write at the end of p. Adding a one liner:
config_sz += sizeof(config_template);
to line mok.c line 998 should resolve it.

[jyong2]

Strange, line 998 already has it to begin with(?), please ignore my last message.

Edit: not sure how I missed line 998 already having it but looks like the issue is in the 2nd loop where p is advanced by sizeof(config_template) regardless when v->data_size is 0, while the size calculation skips it.

[jyong2]

@jsetje ping? Tested on Tiger Lake, Ice Lake and Comet Lake boards.

[lcp]

For the record, I encountered a firmware crash due to this bug. When booting my testing AArch64 shim, the firmware crashed with the following message:

ASSERT [Fat] /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202105/FatPkg/EnhancedFatDxe/DirectoryCache.c(146): CR has Bad Signature

It turned out that shim accidentally overwrote the directory cache of the Fat driver and zeroed several fields of struct FAT_ODIR including Signature. With the similar fix as #365, the crash was gone and the system booted as expected.

[frozencemetery]

I think this was closed with #365.

[jsetje]

For folks dealing with shims that don't have this fix:

Another symptom of this bug is that importing a single mok cert will break at least a couple versions of OVMF and hang the system. Since the corruption is caused by overrunning a buffer that's rounded to page size, two certs can be added as a workaround once the system is recovered.

At least on OVMF this symptom is (unsurprisingly) masked by 361.