[BUG] Cannot parse multiple arguments in Tools

[dreamwhite]

Software details

• OpenCore version: 0.8.7 @ release
• Tool that doesn't work: setup_var.efi which accepts multiple arguments

Brief description of the tool

setup_var.efi is a rewritten version of the old modGRUBShell.efi which serves the same purpose: reading/writing UEFI Variables using a command line tool.

The syntax is pretty similar but with this tool you can even pass arguments (with a specific syntax) to itself, without having to use a shell, as done previously with modGRUBShell.efi.

config.plist configuration

Under Misc/Tool context, I added the following dict:

<dict>
	<key>Arguments</key>
	<string>0x527 0x00 -n Setup</string>
	<key>Auxiliary</key>
	<true/>
	<key>Comment</key>
	<string>UEFI command-line tool for read/write access of variables - CFG Lock unlock</string>
	<key>Enabled</key>
	<true/>
	<key>Flavour</key>
	<string>Auto</string>
	<key>FullNvramAccess</key>
	<true/>
	<key>Name</key>
	<string>setup_var - CFG Unlock</string>
	<key>Path</key>
	<string>setup_var.efi</string>
	<key>RealPath</key>
	<true/>
	<key>TextMode</key>
	<true/>
</dict>

Brief description of the bug

When executing the tool, it seems like that only the first argument (0x527) gets passed, while the other are ignored.

How can I tell that? Executing setup_var.efi 0x527 prints the value of such offset but doesn't edit it, with the second argument (0x00).

Temporarily workaround

Setting .\setup_var.efi 0x527 0x00 -n Setup as the value of Arguments fixes the problem but I'm not quite sure that it's the right way of fixing the issue.

Conclusions

Is this a tool-related issue that cannot parse the arguments passed via OpenCore (very unlikely) - therefore this issue doesn't have anything to do with OpenCore -, or is this a potential bug of OpenCore hence it must be fixed?

Thank you so much in advance, and I'm more than willing to eventually test new OpenCore's commits related to this issue.

--
dreamwhite

[mikebeaton]

It's to do with how arguments are passed to a UEFI shell command (argc/argv) vs. passed to an executed UEFI image (a single parameter block, which might not even be text, but typically is), see e.g. https://github.com/acidanthera/OpenCorePkg/blob/master/Library/OcMiscLib/ProtocolSupport.c#L24-L67

If an application wants to support both, then it needs to check which it was passed and, if it was only the latter, to parse the image parameter block for itself. If it's a shell tool, splitting the arguments properly into argc/argv is done for it. We don't pass the shell parameters protocol with split arguments (which would normally only be provided if an image was executed by the UEFI Shell itself).

It looks as if in your case this detection and splitting is being done anyway, then after that the first argument is the tool name and is ignored, so using 0x527 0x00 -n Setup should I believe give exactly the same result as .\setup_var.efi 0x00 -n Setup. Perhaps you could check this.

I feel like you would know about this, but I would have thought that it is not that normal to run this operation in a tool - normally CFG Unlock is something you'd only need to do once? The only obvious time it would get reset and need setting again is after a BIOS update, at which point you definitely need to rescan for the correct (possibly different) offset of the variable, no?

[dreamwhite]

Good morning and thanks for your deep dive explanation. I really appreciate that 😄

how arguments are passed to a UEFI shell command (argc/argv) vs. passed to an executed UEFI image (a single parameter block, which might not even be text, but typically is),

I'm not a C expert, therefore I had some difficulties understanding OC code, but I got your explanation about argc/argv.

so using 0x527 0x00 -n Setup should I believe give exactly the same result as .\setup_var.efi 0x00 -n Setup. Perhaps you could check this

Are you talking about setting it inside Arguments, right? If so, I can make a quick test this evening and report back.

I feel like you would know about this, but I would have thought that it is not that normal to run this operation in a tool...

Yeah, I wrote that """guide""". What do you mean by I would have thought that it is not that normal to run this operation in a tool? Are you talking about the meaning of having such tools under Misc/Tools context? If so, I partially agree with you

The only obvious time it would get reset and need setting again is after a BIOS update, at which point you definitely need to rescan for the correct (possibly different) offset of the variable, no?

Well yeah, despite most of the times the offset of the variable is the same (I tested over 7 different BIOS versions also with other vendors, not just my Dell), it may happen that for weird circumstances:

• a desktop has a faulty CMOS battery and the power outlet is turned off (e.g. manual user intervention, windstorm etc), therefore at each CMOS reset the user must restore the BIOS settings
• a user updates the BIOS and the custom settings gets lost (mainly noticed in Gigabyte boards, but possibly also in others)

In any case however, I thought it would be helpful to have a custom CFG Lock unlock beforehand configured tool entry in OpenCore picker, so user simply starts it and boots the OS (probably needs to power off the PC and turn it on again; N.B. no reboot but literally power-off -> power-on). This may be useful not only for CFG Lock but also for other BIOS settings, that other OSs may require, such as:

• CSM
• TPM
• Intel SGX
• Graphics Configuration related settings

In any case I think the appropriate place where to seek support, since this issue has nothing to do with OpenCore itself, is the issues page of datasone/setup_var.efi.

Thank you so much again for the patience to explain me things and have a nice day 😄