Hi, > 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. > (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. > 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. > And the deafening silence from the shim developers is not an > encouragement either. Indeed. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112129): https://edk2.groups.io/g/devel/message/112129 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] -=-=-=-=-=-=-=-=-=-=-=-
