From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web12.3867.1573853578137664227 for ; Fri, 15 Nov 2019 13:32:58 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cBRqE6Ya; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573853577; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XXfN9ltUOX2OMx1E7NtUPYbg0ct86T+4vpAOKU2eB90=; b=cBRqE6YaT8d7qUdd7acGDEERhNzGKDP+W3gqrXYbgksH2+09g2pKQE1odRjVBRjdUi0+vq mY7MvLKsYNAovIbmPjjNO+doKJSK9/k/mDZfmWWRf/pSRMQG+LkQwmkLGs3tz4t70CIITf kX5TRuj/gQhiV3sv/zUD5gb2KHcp5eI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-106-wUpcQeuPObGVz0PtNEdTug-1; Fri, 15 Nov 2019 16:32:53 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 29DD9107ACC5; Fri, 15 Nov 2019 21:32:52 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-75.ams2.redhat.com [10.36.116.75]) by smtp.corp.redhat.com (Postfix) with ESMTP id 23D7960BF7; Fri, 15 Nov 2019 21:32:50 +0000 (UTC) Subject: Re: [edk2-devel] Interpretation of specification To: Paulo Henrique Lacerda de Amorim References: <30436.1571850762845158639@groups.io> <748ab441-35e4-31d2-1d94-be2a3c4752c8@redhat.com> <7e4784d1-998c-303b-711b-30f6beb33656@riseup.net> From: "Laszlo Ersek" Cc: devel@edk2.groups.io Message-ID: <1be71ed3-54dd-f0f9-1f65-ee88ec25a8e1@redhat.com> Date: Fri, 15 Nov 2019 22:32:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7e4784d1-998c-303b-711b-30f6beb33656@riseup.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: wUpcQeuPObGVz0PtNEdTug-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paulo, On 11/15/19 19:51, Paulo Henrique Lacerda de Amorim wrote: > 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. >=20 > 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= . >=20 > 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). >=20 > - genkeys.sh https://pastebin.com/jjrZGrAB > This is the script im using to create the keys >=20 > - 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. >=20 > - 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. >=20 > 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: >=20 > https://www.dell.com/community/Inspiron/SetVariable-from-UEFI-RuntimeSer= vices-is-not-working-as-expected/m-p/7411885. >=20 >=20 > 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. >=20 > 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: >=20 > "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." >=20 > 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. I'm sorry to say: I have no idea. Composing the payloads of authenticated UEFI variables is one of the most difficult things I've ever done in UEFI code, and whenever that fails for me, digging into even the *open source* variable driver code, to find the exact reason, is a nightmare. Unless you get direct help from Dell, I think your only option is to dump the firmware from your motherboard, and then extract some modules, and disassemble them. I've read that tools exist for this kind of work, but I've never used them. ... Honestly, this is why open source should be the norm. :/ Perhaps you can experiment with other physical UEFI implementations, especially development boards (I seeem to recall names such as "Minnowboard" and "ValleyView" board). I'm sorry that I can't help! Laszlo >=20 > Regards >=20 > Em 24/10/2019 09:33, Laszlo Ersek escreveu: >> On 10/23/19 19:12, phlamorim@riseup.net wrote: >>> The following commit on edk2 added a new a check on format of Authenti= cated variables: https://github.com/tianocore/edk2/commit/c035e37335ae43229= d7e68de74a65f2c01ebc0af ( https://github.com/tianocore/edk2/commit/c035e373= 35ae43229d7e68de74a65f2c01ebc0af ) >>> >>> After this point some implementations started to have differences in t= he 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.ti= anocore.org/show_bug.cgi?id=3D586 where i have seen lots of tools(more on l= inux) 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: http= s://patchew.org/EDK2/1525903747.5882.11.camel@HansenPartnership.com/ ( http= s://patchew.org/EDK2/1525903747.5882.11.camel@HansenPartnership.com/ ) >>> >>> But this patch never got merged, so i realized the tools on linux rece= ived upgrades to work properly with Authentication Variables of the edk2, b= ut the same code just dont worked at a real machine using a ASROCK board. S= o my question is, where the developers should trust to consume the UEFI API= s 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 le= ad 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 remov= e 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 w= rong. >> >> 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 >> >> >>=20 >> >=20