On Tue, Jul 11, 2023 at 04:52:37PM -0700, Taylor Beebe wrote: > In the past, memory protection settings were configured via FixedAtBuild PCDs, > which resulted in a build-time configuration of memory mitigations. This > approach limited the flexibility of applying mitigations to the > system and made it difficult to update or adjust the settings post-build.
Can we have both? Being able to adjust settings at runtime is great. But being able to set them at compile time on the command line (via build --pcd), without patching code, is very useful too. I'd suggest to keep the PCDs, create a profile from PCD settings and use that profile by default. At least for the transition phase and while we don't have good support (yet) to actually manage profiles. Speaking of profile management: What is the longer-term vision here? Have a configuration form in the uefi firmware setup (aka UiApp)? Try adapt settings automatically, for example pick a less strict profile in case an old/broken bootloader triggers a page fault due to using the wrong memory type for allocations? For virtual machine firmware it a good idea to allow picking up the profile configuration from the host. For qemu that can use fw_cfg, similar to the PcdSetNxForStack option we have today. > This patch series also increases the memory protection level for OvmfPkg and > ArmVirtPkg. Not a good idea, especially not using the 'debug' profile (which turns on all guard bits) because that slows down firmware boot alot. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#106853): https://edk2.groups.io/g/devel/message/106853 Mute This Topic: https://groups.io/mt/100090629/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
