Testing if patch has been applied

[adrian77]

First of all, I have not yet ended up in fully automating the solution where my computer boots automatically and apply the patch without the USB dongle. This is since I was still evaluating this approach and had some main concerns, which I am starting to get answers on.

• Will my OS (macOS) and future versions always respect the reserved areas?
• Will the reserved memory persist in hibernation and after wakeup?
• Can something break the automation in future, like OS upgrade it self?

So during this testing period, which I mainly look for program crashes, corrupted files etc , I realised it would be good to verify that the patch has been applied. Let say I reboot computer and forget to apply the patch.
It would be good to check if the patch has been applied. And yes, it's not easy inspect the memory addresses within OS level unless doing some kernel hacks, so I figured using variables would suffice. Using tools like nvram, ioreg in Mac terminal can inspect NMVRAM variables.

So I started to make some code changes to achieve this by gRT->SetVariable(...) with initial issues getting Invalid Parameter. error.
Nevertheless , I had idea to write variables like disable-ram-area-start-0x54dfe544=true. and -end-0x54dffff=true for every range that was disabled allowing me to simply perform nvram -px | grep disable-ram-area to know if the UEFI level memory patch was executed and I was still under root refind UEFI loader.

Any thoughts on this, like other methods to check if patch has been applied?

[MeTalOneOEight]

The OS update scenario is not really handled yet with this utility, since that changes the boot volume automatically to apply the update.
Unfortunately the update can hang/crash if it hits the faulty RAM spots.

[adrian77]

Yes, at least in macOS case, multiple reboots are performed and I think one does not really dare to influence the boot loader chain at this scenario.

[0nelight]

Will my OS (macOS) and future versions always respect the reserved areas?

No way to know for sure. I run Ventura 13.7 and it still works. Depends on future Action of Apple.

Will the reserved memory persist in hibernation and after wakeup?

I don't know how other versions behave, but for me Sleep (S3) and Hibernation (S4) works!

Can something break the automation in future, like OS upgrade it self?

I did upgrade successfully in the past. The way I usually do it is - I but a heavy object on my Option-Key so as soon as a reboot happens, the Built-in Apple Boot-Screen appears to choose Boot Devices. Then I choose my USB Dongle, boot into Refind and execute the disableram patch. Then you have to find the correct Boot-File that the Update would have booted from and choose that in refind. You have to repeat this on every reboot that the update performs.

Regarding check if the patch was applied - so NVRAM wouldn't help you much, because the Patch has to run before every boot. NVRAM means Non-Volatile-RAM so even when you wrote to the nvram a few boots before, it will still show you that the patch run, altough it maybe hadn't.

What should be quite good approach is checking the amount of reserved ram in the terminal. If that number is the same amount you patched, it should have been applied.

sysctl -a | grep mem | grep Unusable

[adrian77]

I was somehow under impression that one could turn off persistency by

  // Use the EFI global variable GUID
    Status = gRT->SetVariable(
        VariableName,
        &GlobalVariableGuid,  // Use the global variable GUID
        EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,  // Non-persistent UEFI variables
        sizeof(Value),
        &Value
    );

But you are right the
sysctl -a | grep mem | grep Unusable
is what I indeed was looking for.
And it shows 0 before patch and
machdep.memmap.Unusable: 33562624
after the patch.

[0nelight]

Ah now I understand what was your Idea! Setting an EFI Variable with EFI_VARIABLE_RUNTIME_ACCESS after running the Patch and then Checking it at runtime from
within MacOS.

With EFI_VARIABLE_RUNTIME_ACCESS the Variable should be indeed avaliable at Runtime of MacOs and at the same time not be part of NVRAM. Question is if the macOS command "nvram -px | grep disable-ram-area" also shows you EFI_VARIABLE_RUNTIME_ACCESS Variables and not only "real" nvram EFI_VARIABLE_NON_VOLATILE Variables.

I currently don't know if there is a way for MacOS accessing efi-runtime-variables during runtime.

[adrian77]

You are right, it is not possible to get these EFI_VARIABLE_RUNTIME_ACCESS without writing a kernel extension. Nor with nvram and ioreg utilities.

Writing parameters to a file in ESP partition that can be accessed from OS is an option.
Then efter boot read file, put in tmp file and delete the UEFI created file. Or skipping the tmp file process completely.
The file would contain ram segments, date of invoking patch. When reading the content one would need to compare the timestamp with uptime output just to ignore potential stale file created by previous boot sessions. E.g. creation time was much older than uptime start.

diskutil list | grep EFI
sudo diskutil mount disk0s1
cat /Volumes/EFI/var/disabled-ram-info.txt

Yes I would have to move my UEFI program to macOS disk with that ESP partition.

Some work, but might not be motivated considering there is alternative of sysctl -a.