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