Im implementing a mechanism which will depends on time based
authenticated variables, but i got stucked when the SetVariable
from RuntimeServices return me a code of Security Violation. I
started to develop my code using the EDK2 and OVMF on QEMU to test
the correctness of my UEFI Applications, and the code worked
properly to set the authenticated variables on OVMF, but when i
tried the same at the Dell Inspiron which uses the AMI
implementation as base of UEFI, i always got a Security Violation
return.
UEFI Spec give a lot of verifications about setting authenticated
variables, and my code worked on the open source reference
implementation, so i got stucked because i cant found out which
validation is making the SetVariable fails on Dell's BIOS
implementation.
Im using an UEFI Application to call the SetVariable twice one for
set the variable file_name and other to set variable file_hash, i
used a script to prepare the payload with the Auth Descriptor
using well known tools: openssl(1.1.1c 28 May 2019) and
sbvarsign(0.9.2).
- genkeys.sh https://pastebin.com/jjrZGrAB
This is the script im using to create the keys
- create_auth_var_files.sh https://pastebin.com/jPQgG0nB
This is the script to generate the payloads used in the UEFI
Application to set the authenticated variables, the toc16 is just
a code to convert an char to CHAR16, the script receive one
parameter, which is a file name, so it create two files
file_name.signed and file_hash.signed, which are the payloads to
set variable file_name and file_hash using time based
authentication.
- TestPkg.c https://pastebin.com/DnwhfuKk This one is the UEFI
Application which call the SetVariable using the payloads
generated by create_auth_var_files.sh, TestPkg is supposed to run
with the file_*.signed in the same path, so it can open and copy
the payload to use on SetVariable.
I tried to follow your suggestion (though i skipped the opensource
plataform "target" because i dont have access to one). As i said,
i'm using a Dell Inspiron, so i opened a thread in Dell Community:
https://www.dell.com/community/Inspiron/SetVariable-from-UEFI-RuntimeServices-is-not-working-as-expected/m-p/7411885.
I informed the BIOS Version which is 2.9.0 from Dell Inc, but
later i receive a private message saying the support in this case
is limited.
I got an output of UEFI v2.40 (American Megatrends, 0x0005000B)
from command ver in the UEFI Shell, i tried to contact the
technical support of AMI, which gave me the following answer:
"Unless
the motherboard is manufactured by AMI, we are not authorized to
provide support for it. The motherboard manufacturers license
our generic BIOS and modify it to fit their motherboard
specifications; thus, we do not have access to the changes made
to the BIOS. For support, BIOS, and driver updates for your
motherboard, please contact your motherboard manufacturer. You
can also contact the place of purchase and inquire if they can
provide assistance for you."
I need to know where in the verification my code is returning a
Security Violation so i can fix, i can provide all the other files
eg: inf and dsc files used to compile the code and the directory
tree im using too.
Regards
On 10/23/19 19:12, phlamorim@riseup.net wrote:The following commit on edk2 added a new a check on format of Authenticated variables: https://github.com/tianocore/edk2/commit/c035e37335ae43229d7e68de74a65f2c01ebc0af ( https://github.com/tianocore/edk2/commit/c035e37335ae43229d7e68de74a65f2c01ebc0af ) After this point some implementations started to have differences in the validation of the format of Authenticator Descriptor as we can se here: https://blog.hansenpartnership.com/uefi-secure-boot/#comment-48351 This case make me reach the following discussions: https://bugzilla.tianocore.org/show_bug.cgi?id=586 where i have seen lots of tools(more on linux) dont generate the correct format to use on the payload for TimeBased authenticated variables, at this time i was just trying to create a private authenticated variable, first thig which worked is to use this patch: https://patchew.org/EDK2/1525903747.5882.11.camel@HansenPartnership.com/ ( https://patchew.org/EDK2/1525903747.5882.11.camel@HansenPartnership.com/ ) But this patch never got merged, so i realized the tools on linux received upgrades to work properly with Authentication Variables of the edk2, but the same code just dont worked at a real machine using a ASROCK board. So my question is, where the developers should trust to consume the UEFI APIs in a trusted way. Another example i had is the path separator "\" or "/", edk2 uses "/" but the spec allow both, ASROCK mix both sometimes it can lead to some errors. I want to know if i can trust if my code work on EDK2 it should work on all other implementations too, and how we will try to remove these ambiguities of interpretation.I suggest writing code against the published UEFI spec, and testing at least with edk2. If edk2 does not behave in accordance with the UEFI spec, then it could be a bug in edk2, or in the spec. Report the issue on edk2-devel, and the community will try to figure out which half is wrong. If your code seems correct, according to both the UEFI spec and to an open source edk2 platform, but it breaks on a particular vendor platform, I suggest talking to that vendor. So, I would suggest the following order of "targets": - spec - reference implementation (edk2) - open source platforms (edk2-platforms) - vendor platform Thanks Laszlo