"unable to find variable store" for "SystemConfig"

[alexceltare2]

I'm trying to disable the "SATA controller" but when i change the variable via UEFI-Shell using setup_var.efi SystemConfig:0x145=0x0 command, i'm met with Error writing variable: No variable with specified name found. Other variables like "SaSetup" work. Bellow is the extracted SetupUtility section.
Section_PE32_image_SetupUtility_SetupUtility.sct.3.0.en-US.uefi.ifr.txt

Also, when i try setup_var.efi Setup:0x145=0x0 i get Error writing variable: Error while setting content of variable Setup: SECURITY_VIOLATION (The function was not performed due to a security violation.)

[datasone]

There seems only be two varstores in this dumped section, with cursed arrangement (same GUID, different names, and a seemed dummy AdvanceConfig):

0x38C5D: 	VarStore Guid: A04A27F4-DF00-4D42-B552-39511302113D, VarStoreId: 0x1234, Size: 0x2BC, Name: "SystemConfig" { 24 23 F4 27 4A A0 00 DF 42 4D B5 52 39 51 13 02 11 3D 34 12 BC 02 53 79 73 74 65 6D 43 6F 6E 66 69 67 00 }
0x38C80: 	VarStore Guid: A04A27F4-DF00-4D42-B552-39511302113D, VarStoreId: 0x1233, Size: 0x8, Name: "AdvanceConfig" { 24 24 F4 27 4A A0 00 DF 42 4D B5 52 39 51 13 02 11 3D 33 12 08 00 41 64 76 61 6E 63 65 43 6F 6E 66 69 67 00 }

In the UEFI specification, name and GUID are used jointly to specify the variable store, so it should not be a wrong configuration or IFR extraction. But it makes reading/writing values much more tricky.

I wrote a small tool to dump all varstores with their GUIDs and names directly in bytes, if you are willing to further diagnostic this problem. Hope it can give us more clear view of how the firmware put those regions.

uefi-dump-vars.zip

As for the SECURITY_VIOLATION problem, it's known that recent laptop OEMs start to keep BIOS setting regions read-only for third-party UEFI applications, to counter tools like this. (So yes, other varstores are highly probably also write protected)

[alexceltare2]

Of course I will chip in for the cause. Bellow are the outputs for the following commands:
dmpstore -all > fs1:\legion_all.txt
uefi-dump-vars.efi > fs1:\uefi-dump-vars.txt

legion_all.txt
uefi-dump-vars.txt

[datasone]

I can't find such varstores, nor something with similar name present in the dumped info.

My guess is that, considering the dumped setting names in the SetupUtility, they may be present in InsydeH2O's reference design, but are chosen to be hard-coded by OEM (the settings are pretty hardware-dependent, and are usually not changeable on laptops or mini PCs). So we can still dump out IFR table from the settings DXE, but the IFR may never be interpreted by the firmware, which leads to creating corresponding var stores and storing values in them. Thus, the setting entries are not practically functional anymore.

[alexceltare2]

It's weird because on the other 2 laptops that i have HP Envy X360 (Intel 2020 with 2025 BIOS) and Lenovo MIIX 510 (Intel 2017), I can change most varnames just fine (SaSetup, Setup(1), PchSetup...) but not SystemConfig. My guess is that they were redirected/renamed somewhere else. I will check to see if "AmdSetup" is the new name for it. I doubt they were locked down since the SECURITY_VIOLATION exception only occurs when I try to modify a unknown variable. (eg setup_var.efi Setup:0x145=0x0 does not correspond to setup_var.efi SystemConfig:0x145=0x0).
My ultimate goal is to be able to change the settings that matter:

• Disable ACPI S0 Idle sleep.
• Enable ACPI S3 sleep.
• Disable VMD Controller.
• Disable SATA Controller.

So far only HP Envy X360 is able to do all of that, maybe HP or Intel have better EFI handling because on my Legion 5 (AMD 2020) has no reference of "AmdSetup" in IRFextractor. By the way, can setup_var.efi reference varstores by GUID and not by varname?

[datasone]

Currently it cannot reference varstores by GUID, and I think it's sufficient, as for varstores sharing the same name, setup_var.efi will print out them with sizes, and instruct user to reference corresponding varstore with a generated ID. And using GUID instead may seem too complicated.

Please point out if there are any circumstances that referencing by GUID is necessary :)

[alexceltare2]

I think you are right in the end. I've did a bit of messing around and the Setup varstore does indeed seem to be protected by SMM or BIOS Lock and even those flags and some interesting varstore flags like CurrentPolicy and SetupMode are write-protected. It's crazy to what lengths will OEMs go to not allow us to tweak our BIOSes.