Package: shim / 15.4-7~deb10u1

Metadata

Package Version Patches format
shim 15.4-7~deb10u1 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
fix import_one_mok_state.patch | (download)

mok.c | 3 0 + 3 - 0 !
1 file changed, 3 deletions(-)

---
fix broken ia32 reloc.patch | (download)

elf_ia32_efi.lds | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

---
MOK BootServicesData.patch | (download)

mok.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
Don t call QueryVariableInfo on EFI 1.10 machines.patch | (download)

mok.c | 23 18 + 5 - 0 !
1 file changed, 18 insertions(+), 5 deletions(-)

 [patch] don't call queryvariableinfo() on efi 1.10 machines

The EFI 1.10 spec (and presumably earlier revisions as well) didn't have
RT->QueryVariableInfo(), and on Chris Murphy's MacBookPro8,2 , that
memory appears to be initialized randomly.

This patch changes it to not call RT->QueryVariableInfo() if the
EFI_RUNTIME_SERVICES table's major revision is less than two, and
assumes our maximum variable size is 1024 in that case.

Signed-off-by: Peter Jones <pjones@redhat.com>

relax_check_for_import_mok_state.patch | (download)

shim.c | 7 5 + 2 - 0 !
1 file changed, 5 insertions(+), 2 deletions(-)

 relax the check for import_mok_state()
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

An openSUSE user reported(*) that shim 15.4 failed to boot the system
with the following message:

  "Could not create MokListXRT: Out of Resources"

In the beginning, I thought it's caused by the growing size of
vendor-dbx. However, we found the following messages after set
SHIM_VERBOSE:

  max_var_sz:8000 remaining_sz:85EC max_storage_sz:9000
  SetVariable(“MokListXRT”, ... varsz=0x1404) = Out of Resources

Even though the firmware claimed the remaining storage size is 0x85EC
and the maximum variable size is 0x8000, it still rejected MokListXRT
with size 0x1404. It seems that the return values from QueryVariableInfo()
are not reliable. Since this firmware didn't really support Secure Boot,
the variable mirroring is not so critical, so we can just accept the
failure of import_mok_state() and continue boot.

(*) https://bugzilla.suse.com/show_bug.cgi?id=1185261

Signed-off-by: Gary Lin <glin@suse.com>

fix_arm64_rela_sections.patch | (download)

Makefile | 4 2 + 2 - 0 !
elf_aarch64_efi.lds | 24 16 + 8 - 0 !
elf_arm_efi.lds | 24 16 + 8 - 0 !
3 files changed, 34 insertions(+), 18 deletions(-)

 [patch] arm/aa64: fix the size of .rela* sections

The previous commit(*) merged .rel* and .dyn* into .rodata, and this
made ld to generate the wrong size for .rela* sections that covered
other unrelated sections. When the EFI image was loaded, _relocate()
went through the unexpected data and may cause unexpected crash.
This commit moves .rel* and .dyn* out of .rodata in the ld script but
also moves the related variables, such as _evrodata, _rodata_size,
and _rodata_vsize, to the end of the new .dyn section, so that the
crafted pe-coff section header for .rodata still covers our new
.rela and .dyn sections.

(*) 212ba30544f ("arm/aa64 targets: put .rel* and .dyn* in .rodata")

Fix issue: https://github.com/rhboot/shim/issues/371

Signed-off-by: Gary Lin <glin@suse.com>