On 2022-02-28 19:45, Ard Biesheuvel wrote:
(cc Matt and Peter)
Thanks for exploring my suggestion to use the DXE services for this.
Given that this is a workaround for a very specific issue arising on
PI based implementations of UEFI, I consider this a quirk, and so I
think this approach is reasonable. I'd still like to gate it on some
kind of identification, though - perhaps something related to DMI like
the x86 core kernel does as well.
I've cc'ed Peter and Matt, who have much more experience dealing with
these kinds of things on x86 - my experience is mostly based on ARM,
which tends to be less quirky when it comes to UEFI support, given
that vendors that implement EFI actually care about being compliant
(instead of only about getting a windows sticker)
Matt, Peter, any thoughts?
Baskov Evgeniy (2):
efi: declare DXE services table
libstub: ensure allocated memory to be executable
arch/x86/include/asm/efi.h | 5 ++
drivers/firmware/efi/libstub/efistub.h | 53 ++++++++++++++++++++
drivers/firmware/efi/libstub/x86-stub.c | 73
++++++++++++++++++++++++++--
include/linux/efi.h | 2 +
4 files changed, 128 insertions(+), 5 deletions(-)
We now have tested the patch on major platforms, and it works without
any
issues. But in case of firmware bugs I have changed the code to only
modify attributes if either EFI_MEMORY_RO or EFI_MEMORY_WP is set and
the memory has type EfiGcdMemoryTypeSystemMemory.
I also added option CONFIG_EFI_DXE_MEM_ATTRIBUTES (enabled by default),
to allow this code to be disabled at compile time.
These changes will be sent in version 3 of the patch.
Thanks,
Baskov Evgeniy
