But what we might do is invent a way to avoid setting the XP attribute
on the entire region based on some heuristic. Given that the main
purpose of the EFI memory attribute protocol is to provide the ability
to remove XP (and set RO instead), perhaps we can avoid the set
entirely? Just brainstorming here.
Can the fault handler deal with this? Set a flag somewhere, print a
big'n'fat error message, wait 5 secs, reset machine? After reset the
firmware will see the flag and come up in 'compat' instead of 'strict'
mode.
Not sure what a good place for such a flag would be. Do we have other
options than a non-volatile efi variable? When using a efi variable we
probably should add an 'expires' timestamp, so the machine doesn't stay
in 'compat' mode forever.
This is what we do in Project Mu currently and is what we would like to
push into
EDK2. For x86 platforms, we use CMOS to communicate to the next boot
that the
system needs to enter compatibility mode. Of course this doesn't work on ARM
platforms, so we'll have to come up with a more permanent mechanism to
support
this functionality.
(cc'ing Taylor and Oliver given that this is related to the memory
policy work as well) Perhaps we can use the fact that the active image
is non-NX compat to make some tweaks?
Memory policies would be another candidate which could possibly use a
less strict profile in 'compat' mode. I'd love to see memory policies
land for the February stable tag.
I don't think the policy can change how the SHIM sets attributes using the
protocol, but you can hook the installation of the Memory Attribute
Protocol into the policy system so it's not installed in compat mode.
I have not revisited the memory protection policy interface update
since Lazlo's feedback in October, but I'd be happy to return to it if
there's
motivation to get it in over the finish line. Note that there are more
changes
that will need to be made to add testing, compat mode
switching, support for the nx_compat flag, etc. The patch series that's
currently in flight is just meant to be a lateral move to a runtime
configurable
interface.
What I really want to avoid is derail our effort to tighten things
down and comply with the NX compat related policies, by adding some
build time control that the distros will enable now and never disable
again, citing backward compat concerns.
Sure, I want that too. Having an runtime switch is already an
improvement over having a compile time switch. Having this working
fully automatic would be even better of course.
If a fix for this issue is needed immediately, I'm fine with Ard's
solution as a stop-gap.
Assuming we can make progress on committing the memory protection updates,
I can update the CpuDxe drivers to check the memory protection policy
before installing the Memory Attribute Protocol. When adding this policy
config,
I would revert the change made here to uninstall the protocol.
Thanks :)
-Taylor
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112138): https://edk2.groups.io/g/devel/message/112138
Mute This Topic: https://groups.io/mt/102967690/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
