>> 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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-