EFI_MEMORY_ATTRIBUTE_PROTOCOL cause Synchronous Exception when booting Linux

[andreamtp]

On many widespread linux distros (Fedora 39, ...) esp. LTS ones (Ubuntu 22.04, RHEL/CentOS Stream (and derived) rel 9, ...) is shipped a version of rhboot's shim that does not work when the newly added EFI_MEMORY_ATTRIBUTE_PROTOCOL is provided by the firmware, causing a Synchronous Exception error when booting the OS.

Many distros haven't updated yet, so uninstall the protocol could be a workaround for the time being.

This has been introduced by the release 1.2 of this port of edk2 for rk356x.

The issue has been already addressed in the edk2 porting for rk3588:

edk2-porting/edk2-rk3588@842db13

Is it possible to introduce it here as well?

Ref:

• [Bug]: Code marked as NX when boot Ubuntu microsoft/mu_silicon_arm_tiano#124
• https://edk2.groups.io/g/devel/topic/99631663

[andreamtp]

Hi @jaredmcneill , have you had time to take a look at this and figure it out?
Will you wait for a fixed shim - so we need to backport it in the linux OS or to downgrade the edk2 firmware - or will you adopt a more user friendly approach implementing some fixes in this edk2 port?

Thanks for your great job and to share the way the project will address this issue.

[jaredmcneill]

I posted a proposed patch (untested!) in the topic/jmcneill/pr73 branch:

main...topic/jmcneill/pr73

Can you try it? EFI_MEMORY_ATTRIBUTE_PROTOCOL still enabled by default, but with this change you should see a config entry in the setup menu to let you turn it off.

[andreamtp]

Hi @jaredmcneill , I've successfully built the branch, but I faced some issues:

1. Changes to the parameters done via UI are not persisted. Trying to disable the feature via UI works as expected (set the flag, save, reset) but values are not persisted: after reset, they go back to their defaults.
   I've tried this also with other params and this bug is consistent and was preset also in 1.1 and 1.2 releases as well, when tianocore is deployed either on SD card or eMMC
2. You mentioned that the feature remain enabled by default. The help state "Disable EFI_MEMORY_ATTRIBUTE_PROTOCOL support to work around buggy Linux distributions." so if we want that enable, the field need to be empty. Is it wanted that the code under the hood revert the logic and set a default to 1 (enable) but to the user is present with opposite logic?

3. I've tried to force the disable the feature, by editing the code this way:

edk2-rockchip/Platform/Rockchip/Rk356x/Drivers/ConfigDxe/ConfigDxeHii.vfr

        checkbox varid = MemAttrProtocolEnable.Enable,
            prompt      = STRING_TOKEN(STR_SYSCONFIG_MEMATTR_PROMPT),
            help        = STRING_TOKEN(STR_SYSCONFIG_MEMATTR_HELP),
            flags       = CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG | RESET_REQUIRED,
            default     = 0,
       endcheckbox;

But this change:
- Is not reflected in the UI: the field is always empty
- does not trigger the new code (the boot stuck with the usual "Synchronous Exception at 0x0000000000EA872000"

Thanks for the backport effort: sorry for the delay in testing, missed the GH notification...

[andreamtp]

Up ;-)

[jaredmcneill]

Found a typo in the proposed patch and pushed an update, please update your tree and try again.

With regards to not persisting UEFI env vars to SD or eMMC, let's track that in a separate issue.

[andreamtp]

Found a typo in the proposed patch and pushed an update, please update your tree and try again.

New release, after setting in edk2-rockchip/Platform/Firefly/ROC-RK3566-PC/ROC-RK3566-PC.dsc from:

gRk356xTokenSpaceGuid.PcdMemAttrProtocolEnable|L"MemAttrProtocolEnable"|gConfigDxeFormSetGuid|0x0|1

to

gRk356xTokenSpaceGuid.PcdMemAttrProtocolEnable|L"MemAttrProtocolEnable"|gConfigDxeFormSetGuid|0x0|0

because it was impossible to set it off and make it persistent.

System booted correctly Fedora Linux 39 (kernel 6.5.6-300) without updates to the shim, so the patch works!

Currently I've tested it by having firmware loaded from SD card.

With regards to not persisting UEFI env vars to SD or eMMC, let's track that in a separate issue.

Ok , opened #83

Thanks