;
Fri, 15 Nov 2019 10:51:37 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@riseup.net header.s=squak header.b=aTGcUnwZ;
spf=pass (domain: riseup.net, ip: 198.252.153.129, mailfrom: phlamorim@riseup.net)
Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id 47F6rm3rJfzFZt8;
Fri, 15 Nov 2019 10:51:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1573843896; bh=ASBb7U6LoKqM/D8nDchgZpoFF3lcI6xePdVMhpfxlsE=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=aTGcUnwZoxQFmJoK1D8XtSt4T5d5lKpARHpP8AwQn7mFzGcS8ovjgAdLqSyVg6Eq8
9itOHBJTDnZteS8hZKaTPglooRuaoIxz021cWy0gnNtW2MFgIXoG2kmOQAcJEBETEV
DuGl5iG2aUhQoF5/fBxzAxpbuLS6Y57FUWf2jwM4=
X-Riseup-User-ID: 6F6B024A8FE89C0098326ED5362323E7DA3ACCFE11134E1DC02DDCD020B9C97B
Received: from [127.0.0.1] (localhost [127.0.0.1])
by capuchin.riseup.net (Postfix) with ESMTPSA id 47F6rl2wyxz8sXb;
Fri, 15 Nov 2019 10:51:35 -0800 (PST)
Subject: Re: [edk2-devel] Interpretation of specification
To: devel@edk2.groups.io, lersek@redhat.com
References: <30436.1571850762845158639@groups.io>
<748ab441-35e4-31d2-1d94-be2a3c4752c8@redhat.com>
From: phlamorim@riseup.net
Message-ID: <7e4784d1-998c-303b-711b-30f6beb33656@riseup.net>
Date: Fri, 15 Nov 2019 15:51:31 -0300
MIME-Version: 1.0
In-Reply-To: <748ab441-35e4-31d2-1d94-be2a3c4752c8@redhat.com>
Content-Type: multipart/alternative;
boundary="------------17754C49575D68596E73B8AC"
Content-Language: en-US
--------------17754C49575D68596E73B8AC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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
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 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
>
>
>
>
--------------17754C49575D68596E73B8AC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
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
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 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
--------------17754C49575D68596E73B8AC--
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
From mboxrd@z Thu Jan 1 00:00:00 1970
Subject: Re: [edk2-devel] Interpretation of specification
To: Paulo Henrique Lacerda de Amorim ,devel@edk2.groups.io
From: "Eugene Khoruzhenko"
X-Originating-Location: Redmond, Washington, US (50.47.110.221)
X-Originating-Platform: Windows Chrome 78
User-Agent: GROUPS.IO Web Poster
MIME-Version: 1.0
Date: Fri, 22 Nov 2019 20:59:32 -0800
References: <7e4784d1-998c-303b-711b-30f6beb33656@riseup.net>
In-Reply-To: <7e4784d1-998c-303b-711b-30f6beb33656@riseup.net>
Message-ID: <9504.1574485172591155571@groups.io>
Content-Type: multipart/alternative; boundary="DKzebmhXA9RLqiINVADT"
--DKzebmhXA9RLqiINVADT
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi Paulo,
Just to be clear - your variables have your own GUID and Name, so your var=
iables are "common" Authenticated Variables, correct? What exactly is faili=
ng in your case:
* You cannot write your variable first time, so it does not get created?
* Or you can create, but cannot update after it's been created?
I seem to be able to create my Authenticated Variables on a number of prod=
uction devices, including Dell, but then these variables cannot be deleted.=
I see exactly why deletion does not work - bug https://bugzilla.tianocore.=
org/show_bug.cgi?id=3D2374 , but this issue is specific to deletion only.
--DKzebmhXA9RLqiINVADT
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi Paulo,
Just to be clear - your variables have your own GUID a=
nd Name, so your variables are "common" Authenticated Variables, correct? W=
hat exactly is failing in your case:
- You cannot write your variable first time, so it does not get created?=
- Or you can create, but cannot update after it's been created?
I seem to be able to create my Authenticated Variables on a number of prod=
uction devices, including Dell, but then these variables cannot be deleted.=
I see exactly why deletion does not work - bug https://bugzilla.tianocore.org/=
show_bug.cgi?id=3D2374, but this issue is specific to deletion only.
--DKzebmhXA9RLqiINVADT--
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by mx.groups.io with SMTP id smtpd.web11.6553.1574514501070220768
for ;
Sat, 23 Nov 2019 05:08:21 -0800
Authentication-Results: mx.groups.io;
dkim=fail reason="body hash did not verify" header.i=@riseup.net header.s=squak header.b=IO2YpC15;
spf=pass (domain: riseup.net, ip: 198.252.153.129, mailfrom: phlamorim@riseup.net)
Received: from capuchin.riseup.net (unknown [10.0.1.176])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id 47Kts03mj1zFcH9;
Sat, 23 Nov 2019 05:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1574514500; bh=HSVOfKHJSmJYErcflFrmaBCibvyq+QVMOe5ORxlhXpY=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=IO2YpC153fk+Mv+zzk98EYVnqBTpaFFB4yHbgJDHWniFiTk6Dm2B+pWZLaEFDvaAX
i3uTEdOu4zoAsXiEk1SGC3h5l7osehG6Yg7+cMgxp9TpQeC2ojPfeaQmCMWBmwp8FQ
UxSa6CltxO+se3Euh24c+7RlNVnnymUHURnFzMFo=
X-Riseup-User-ID: 15F31E70C362955402EAA2B6E174DF55B19CF1CA715E1F577410FAA6FF5ACEC4
Received: from [127.0.0.1] (localhost [127.0.0.1])
by capuchin.riseup.net (Postfix) with ESMTPSA id 47Ktrz4cZbz8tTd;
Sat, 23 Nov 2019 05:08:19 -0800 (PST)
Subject: Re: [edk2-devel] Interpretation of specification
To: devel@edk2.groups.io, sun2sirius@gmail.com
References: <7e4784d1-998c-303b-711b-30f6beb33656@riseup.net>
<9504.1574485172591155571@groups.io>
From: "Paulo Henrique Lacerda de Amorim"
Message-ID: <8bcef1fa-c8a4-2b1b-dcd3-adb45cc7254e@riseup.net>
Date: Sat, 23 Nov 2019 10:08:16 -0300
MIME-Version: 1.0
In-Reply-To: <9504.1574485172591155571@groups.io>
Content-Type: multipart/alternative;
boundary="------------CE4271AE2337AECB00E9DBF8"
Content-Language: en-US
--------------CE4271AE2337AECB00E9DBF8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Correct, im using my own GUID and Name, they started to name theses
variables Private Authenticated Variables since UEFI 2.7 as stated in
the session on how the firmware validate the payload to SetVariable
using EFI_VARIABLE_AUTHENTICATION2 descriptor:
"Otherwise, if the variable is none of the above, it shall be designated
a Private Authenticated Variable..."
In my case the first write is failing, i got a Security Violation return
when trying to create the variable, you used Key/cert which chains to
PK/KEK when creating variables on production devices? Maybe im missing
something. Let me know if i need to provide more information, as i
stated before i can provide the same scripts/sources im using.
Thanks in advance.
Em 23/11/2019 01:59, Eugene Khoruzhenko escreveu:
> Hi Paulo,
>
> Just to be clear - your variables have your own GUID and Name, so your
> variables are "common" Authenticated Variables, correct? What exactly
> is failing in your case:
>
> * You cannot write your variable first time, so it does not get create=
d?
> * Or you can create, but cannot update after it's been created?
>
> I seem to be able to create my Authenticated Variables on a number of
> production devices, including Dell, but then these variables cannot be
> deleted. I see exactly why deletion does not work -
> bug=C2=A0https://bugzilla.tianocore.org/show_bug.cgi?id=3D2374, but this
> issue is specific to deletion only.
>=20
--------------CE4271AE2337AECB00E9DBF8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Correct, im using my own GUID and Name, they started to name
theses variables Private Authenticated Variables since UEFI 2.7 as
stated in the session on how the firmware validate the payload to
SetVariable using EFI_VARIABLE_AUTHENTICATION2 descriptor:
"Otherwise,
if the variable is none of the above, it shall be designated a
Private Authenticated Variable..."
In my case the first write is failing,
i got a Security Violation return when trying to create the
variable, you used Key/cert which chains to PK/KEK when creating
variables on production devices? Maybe im missing something. Let
me know if i need to provide more information, as i stated before
i can provide the same scripts/sources im using.
Thanks in advance.
Em 23/11/2019 01:59, Eugene Khoruzhenko escreveu:
Hi Paulo,
Just to be clear - your variables have your own GUID and Name, so
your variables are "common" Authenticated Variables, correct? What
exactly is failing in your case:
- You cannot write your variable first time, so it does not
get created?
- Or you can create, but cannot update after it's been
created?
I seem to be able to create my Authenticated Variables on a number
of production devices, including Dell, but then these variables
cannot be deleted. I see exactly why deletion does not work - bug=C2=
=
=A0https://bugzilla.tianocore.org/show_bug.c=
gi?id=3D2374,
but this issue is specific to deletion only.
--------------CE4271AE2337AECB00E9DBF8--
From mboxrd@z Thu Jan 1 00:00:00 1970
Subject: Re: [edk2-devel] Interpretation of specification
To: Paulo Henrique Lacerda de Amorim ,devel@edk2.groups.io
From: "Eugene Khoruzhenko"
X-Originating-Location: Redmond, Washington, US (50.47.110.221)
X-Originating-Platform: Windows Chrome 78
User-Agent: GROUPS.IO Web Poster
MIME-Version: 1.0
Date: Mon, 25 Nov 2019 22:08:43 -0800
References: <8bcef1fa-c8a4-2b1b-dcd3-adb45cc7254e@riseup.net>
In-Reply-To: <8bcef1fa-c8a4-2b1b-dcd3-adb45cc7254e@riseup.net>
Message-ID: <17919.1574748523014243625@groups.io>
Content-Type: multipart/alternative; boundary="ge8KcLGvwNlbqXQuNBvA"
--ge8KcLGvwNlbqXQuNBvA
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
No, we do not have access to the manufacturer's PK/KEK, so I created my own=
keys and certs. Theoretically, to debug this you can send me the GUID/Name=
and payload you are trying to write, I can check if I can write your varia=
ble with my tool and signing. Then I could look at your code and compare wi=
th mine and see why it does not work. If your code works on my devices, may=
be the specific model you have has some issue? BTW, try the other vendors, =
like Lenovo and HP.=C2=A0I only cannot promise when I will be able to get t=
o it with holidays approaching and many other things to do...
--ge8KcLGvwNlbqXQuNBvA
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
No, we do not have access to the manufacturer's PK/KEK, so I created my own=
keys and certs. Theoretically, to debug this you can send me the GUID/Name=
and payload you are trying to write, I can check if I can write your varia=
ble with my tool and signing. Then I could look at your code and compare wi=
th mine and see why it does not work. If your code works on my devices, may=
be the specific model you have has some issue? BTW, try the other vendors, =
like Lenovo and HP. I only cannot promise when I will be able to get t=
o it with holidays approaching and many other things to do...
--ge8KcLGvwNlbqXQuNBvA--
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by mx.groups.io with SMTP id smtpd.web12.13291.1574781752698544734
for ;
Tue, 26 Nov 2019 07:22:33 -0800
Authentication-Results: mx.groups.io;
dkim=fail reason="body hash did not verify" header.i=@riseup.net header.s=squak header.b=CooC5Uqf;
spf=pass (domain: riseup.net, ip: 198.252.153.129, mailfrom: phlamorim@riseup.net)
Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id 47MnhS0qrJzDvG3;
Tue, 26 Nov 2019 07:22:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1574781752; bh=l/3OQZtDJXVy1KUeleH6f8Bml7Av5qiSdv3ROIjP6PI=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=CooC5UqfwDJLCEHUTin2UGqp4GJJwmPi9akmitrfTTZqcbWYddq5Gjoy5geyFlNQM
6m/03QhTW/wNlTlAFJxrjR909ea5prlQUdXSQwrL2RGobDLv4a0R54Ll96kfU+lCDe
VTUAFWHpI1PPedMhUqIadBYaPQUiBEJcUzkS+xhE=
X-Riseup-User-ID: D52F7E994C0AF9F625227EC527D8D7FFCE464193D82FF7AD50D8D43DA49C3FE0
Received: from [127.0.0.1] (localhost [127.0.0.1])
by bell.riseup.net (Postfix) with ESMTPSA id 47MnhR2ZfqzJqWS;
Tue, 26 Nov 2019 07:22:31 -0800 (PST)
Subject: Re: [edk2-devel] Interpretation of specification
To: devel@edk2.groups.io, sun2sirius@gmail.com
References: <8bcef1fa-c8a4-2b1b-dcd3-adb45cc7254e@riseup.net>
<17919.1574748523014243625@groups.io>
From: "Paulo Henrique Lacerda de Amorim"
Message-ID: <0daf62c6-f746-9e3c-bc01-e32b11161b6f@riseup.net>
Date: Tue, 26 Nov 2019 12:22:28 -0300
MIME-Version: 1.0
In-Reply-To: <17919.1574748523014243625@groups.io>
Content-Type: multipart/alternative;
boundary="------------6DA6216AF0F7E7FF5EA4F433"
Content-Language: en-US
--------------6DA6216AF0F7E7FF5EA4F433
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
The GUID im using is 301d199a-4dc1-4b26-b557-a012d83d7a52 and the
variable names are file_name and file_hash, im using the following
script to generate my key/cert.
genkeys.sh: https://pastebin.com/iYEFLQD7
The payloads im trying to write is generated using a small script which
receive a single parameter which is a file name, the script just create
two files, file_name.txt with the file name converted to CHAR16 and
file_hash.txt with the SHA512 of the contents of the file. Then the
script uses sbvarsign to sign both, creating file_name.signed and
file_hash.signed using the previous generated keys.
create_auth_var_files.sh: https://pastebin.com/XhV9RbEB
Then with the payloads(file_name.signed and file_hash.signed) in the
same directory of my UEFI Application i run the application from the
UEFI Shell, which open these files, copy to a buffer and use them when
calling SetVariable.
TestPkg.c: https://pastebin.com/LbYvvrWH
The to16 is just a poor program to turn the passed parameter to
auth_create_var_files.sh in a valid CHAR16 string, as following
https://pastebin.com/AhjdzQrC.
The UEFI Application is just the TestPkg.c, i can upload the .inf and
.dsc files too if you want, and warn me if you want more information.
Em 26/11/2019 03:08, Eugene Khoruzhenko escreveu:
> No, we do not have access to the manufacturer's PK/KEK, so I created
> my own keys and certs. Theoretically, to debug this you can send me
> the GUID/Name and payload you are trying to write, I can check if I
> can write your variable with my tool and signing. Then I could look at
> your code and compare with mine and see why it does not work. If your
> code works on my devices, maybe the specific model you have has some
> issue? BTW, try the other vendors, like Lenovo and HP.=C2=A0I only canno=
t
> promise when I will be able to get to it with holidays approaching and
> many other things to do...
>=20
--------------6DA6216AF0F7E7FF5EA4F433
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
The GUID im using is 301d199a-4dc1-4b26-b557-a012d83d7a52 and the
variable names are file_name and file_hash, im using the following
script to generate my key/cert.
genkeys.sh: https://pastebin.com/iYEFLQD7
The payloads im trying to write is generated using a small script
which receive a single parameter which is a file name, the script
just create two files, file_name.txt with the file name converted
to CHAR16 and file_hash.txt with the SHA512 of the contents of the
file. Then the script uses sbvarsign to sign both, creating
file_name.signed and file_hash.signed using the previous generated
keys.
create_auth_var_files.sh: https://pastebin.com/XhV9RbEB
Then with the payloads(file_name.signed and file_hash.signed) in
the same directory of my UEFI Application i run the application
from the UEFI Shell, which open these files, copy to a buffer and
use them when calling SetVariable.
TestPkg.c:
https://pastebin.com/LbYvvrWH
The to16 is just a poor program to turn the passed parameter to
auth_create_var_files.sh in a valid CHAR16 string, as following
https://pastebin.com/AhjdzQrC.
The UEFI Application is just the TestPkg.c, i can upload the .inf
and .dsc files too if you want, and warn me if you want more
information.
Em 26/11/2019 03:08, Eugene Khoruzhenko escreveu:
No, we do not have access to the manufacturer's PK/KEK, so I
created my own keys and certs. Theoretically, to debug this you
can send me the GUID/Name and payload you are trying to write, I
can check if I can write your variable with my tool and signing.
Then I could look at your code and compare with mine and see why
it does not work. If your code works on my devices, maybe the
specific model you have has some issue? BTW, try the other
vendors, like Lenovo and HP.=C2=A0I only cannot promise when I will =
be
able to get to it with holidays approaching and many other things
to do...
--------------6DA6216AF0F7E7FF5EA4F433--
From mboxrd@z Thu Jan 1 00:00:00 1970
Subject: Re: [edk2-devel] Interpretation of specification
To: Paulo Henrique Lacerda de Amorim ,devel@edk2.groups.io
From: "Eugene Khoruzhenko"
X-Originating-Location: Redmond, Washington, US (50.35.77.204)
X-Originating-Platform: Windows Chrome 79
User-Agent: GROUPS.IO Web Poster
MIME-Version: 1.0
Date: Fri, 03 Jan 2020 11:52:56 -0800
References: <0daf62c6-f746-9e3c-bc01-e32b11161b6f@riseup.net>
In-Reply-To: <0daf62c6-f746-9e3c-bc01-e32b11161b6f@riseup.net>
Message-ID: <9658.1578081176951253055@groups.io>
Content-Type: multipart/alternative; boundary="GRm0b3hasBf1XTdgiNWc"
--GRm0b3hasBf1XTdgiNWc
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi Paulo, I finally got to looking into this and I was able to replicate yo=
ur experiment. I created the payloads with your scripts and tried to write =
the "file_name" one with my firmware code and I get the error. So the probl=
em may be not with the TestPkg.c but the way payloads are generated. I'll t=
ry to dig deeper and compare with my code that works OK, and figure it out =
if you want.
--GRm0b3hasBf1XTdgiNWc
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi Paulo, I finally got to looking into this and I was able to replicate yo=
ur experiment. I created the payloads with your scripts and tried to write =
the "file_name" one with my firmware code and I get the error. So the probl=
em may be not with the TestPkg.c but the way payloads are generated. I'll t=
ry to dig deeper and compare with my code that works OK, and figure it out =
if you want.
--GRm0b3hasBf1XTdgiNWc--
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by mx.groups.io with SMTP id smtpd.web09.9259.1578158267870304393
for ;
Sat, 04 Jan 2020 09:17:48 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@riseup.net header.s=squak header.b=L0WB9pio;
spf=pass (domain: riseup.net, ip: 198.252.153.129, mailfrom: phlamorim@riseup.net)
Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id 47qpPR2Cm8zDqgt;
Sat, 4 Jan 2020 09:17:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1578158267; bh=TT6lTIpidqhpTHgXwvKLXEsnw3w3PiBb8VcJt0oNZ4c=;
h=Subject:To:References:From:Date:In-Reply-To:From;
b=L0WB9pio1e36gcPS6w82WiUIFLYTTp71qBC//DrH17Hq+Wse4nQraFzabmtAVWogw
TeZWME5y1ZTmVtE6aTFfWxt5dh3uPSgQNCznade8dvlMryMGwzCzKxBz83NkiUGy5D
v0ab35zHt4J2BN4apVu23vipc5Vjlavm82pifYVo=
X-Riseup-User-ID: E911A493E0637466C872BB8C0315076A61AEA083B0E6B2317DD3B90169174AFA
Received: from [127.0.0.1] (localhost [127.0.0.1])
by bell.riseup.net (Postfix) with ESMTPSA id 47qpPQ3TwBzJrXx;
Sat, 4 Jan 2020 09:17:46 -0800 (PST)
Subject: Re: [edk2-devel] Interpretation of specification
To: devel@edk2.groups.io, ekhoruzhenko@absolute.com
References: <0daf62c6-f746-9e3c-bc01-e32b11161b6f@riseup.net>
<9658.1578081176951253055@groups.io>
From: "Paulo Henrique Lacerda de Amorim"
Message-ID:
Date: Sat, 4 Jan 2020 14:17:43 -0300
MIME-Version: 1.0
In-Reply-To: <9658.1578081176951253055@groups.io>
Content-Type: multipart/alternative;
boundary="------------AD4BA51826AF31094A52169D"
Content-Language: en-US
--------------AD4BA51826AF31094A52169D
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
I Appreciate you replicated my experiment, and for sure it will be
helpful if you can figure out where the payload is wrong.
Let me know if i should provide more info.
Em 03/01/2020 16:52, Eugene Khoruzhenko escreveu:
> Hi Paulo, I finally got to looking into this and I was able to
> replicate your experiment. I created the payloads with your scripts
> and tried to write the "file_name" one with my firmware code and I get
> the error. So the problem may be not with the TestPkg.c but the way
> payloads are generated. I'll try to dig deeper and compare with my
> code that works OK, and figure it out if you want.
>
--------------AD4BA51826AF31094A52169D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
I Appreciate you replicated my experiment, and for sure it will
be helpful if you can figure out where the payload is wrong.
Let me know if i should provide more info.
Em 03/01/2020 16:52, Eugene Khoruzhenko
escreveu:
Hi Paulo, I finally got to looking into this and I was able to
replicate your experiment. I created the payloads with your
scripts and tried to write the "file_name" one with my firmware
code and I get the error. So the problem may be not with the
TestPkg.c but the way payloads are generated. I'll try to dig
deeper and compare with my code that works OK, and figure it out
if you want.
--------------AD4BA51826AF31094A52169D--
From mboxrd@z Thu Jan 1 00:00:00 1970
Subject: Re: [edk2-devel] Interpretation of specification
To: Paulo Henrique Lacerda de Amorim ,devel@edk2.groups.io
From: "Eugene Khoruzhenko"
X-Originating-Location: Redmond, Washington, US (50.35.77.204)
X-Originating-Platform: Windows Chrome 79
User-Agent: GROUPS.IO Web Poster
MIME-Version: 1.0
Date: Tue, 07 Jan 2020 10:13:13 -0800
References:
In-Reply-To:
Message-ID: <6038.1578420793574513591@groups.io>
Content-Type: multipart/alternative; boundary="o4B3RBLW7dAjIq6Nfj2d"
--o4B3RBLW7dAjIq6Nfj2d
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
I think I may have found the problem. I can write the file_name.signed crea=
ted by your scripts in NT32 emulated environment and in EDKII on Minnow boa=
rd that I build myself. However, I cannot write the file_name.signed on a c=
ommercial device. I can write the same authenticate variable with the same =
Name/GUID and same cert/key on a device when I create the payload in a UEFI=
Shell app. So the only difference is creating the signed payload by sbvars=
ign in Ubuntu vs doing it in UEFI. I compared both the working and non-work=
ing payloads and the main difference I see is in the timestamp. For some re=
ason sbvarsign writes the Year as 0x0078 (120) vs the UEFI app writing 0x07=
e4 (2020). The month/day/hour/min seems to be OK, but the year is really of=
f in the sbvarsign's payload. I cannot prove it, but I think the commercial=
firmware may be having a sanity check for the timestamp date/time, e.g. co=
mpare with the device manufacture date. Since sbvarsign does not allow sett=
ing a timestamp separately, I cannot force it to create a payload with the =
correct year.
--o4B3RBLW7dAjIq6Nfj2d
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
I think I may have found the problem. I can write the file_name.signed crea=
ted by your scripts in NT32 emulated environment and in EDKII on Minnow boa=
rd that I build myself. However, I cannot write the file_name.signed on a c=
ommercial device. I can write the same authenticate variable with the same =
Name/GUID and same cert/key on a device when I create the payload in a UEFI=
Shell app. So the only difference is creating the signed payload by <=
span style=3D"color: #000000; font-family: Menlo, Monaco, Consolas, 'Courie=
r New', monospace; font-size: 13px;">sbvarsign in Ubuntu vs doi=
ng it in UEFI. I compared both the working and non-working payloads and the=
main difference I see is in the timestamp. For some reason sbvarsign write=
s the Year as 0x0078 (120) vs the UEFI app writing 0x07e4 (2020). The month=
/day/hour/min seems to be OK, but the year is really off in the sbvarsign's=
payload. I cannot prove it, but I think the commercial firmware may be hav=
ing a sanity check for the timestamp date/time, e.g. compare with the devic=
e manufacture date. Since sbvarsign does not allow setting a timestamp sepa=
rately, I cannot force it to create a payload with the correct year.
--o4B3RBLW7dAjIq6Nfj2d--
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81])
by mx.groups.io with SMTP id smtpd.web12.6440.1578482660074546480
for ;
Wed, 08 Jan 2020 03:24:20 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EsQxzWq8;
spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1578482659;
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=Swuj93rLp6Zx3tXot3b9u6kMaNluDeyHT6uLVXv90h0=;
b=EsQxzWq8G0j/Ss1UCug2YTRkE69D8srDBnCHdoLoJQSFCD2bSfYWX8urUhA5vishAMQszP
+urDPjODbHgp+sWg1+LPvtT4GnSWYOTztpHqspZNIYTGyoSCRXO4v5zXqgYtcKEID95BoL
oyNpTcAUQt1h5VcpprA1X40t1A76TeI=
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-249-RPenlTLjPqSZN0a3Pz82Nw-1; Wed, 08 Jan 2020 06:24:17 -0500
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4216B10509F6;
Wed, 8 Jan 2020 11:24:16 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-37.ams2.redhat.com [10.36.117.37])
by smtp.corp.redhat.com (Postfix) with ESMTP id E035C277C0;
Wed, 8 Jan 2020 11:24:14 +0000 (UTC)
Subject: Re: [edk2-devel] Interpretation of specification
To: ekhoruzhenko@absolute.com
References:
<6038.1578420793574513591@groups.io>
From: "Laszlo Ersek"
Cc: devel@edk2.groups.io,
Paulo Henrique Lacerda de Amorim ,
James Bottomley
Message-ID:
Date: Wed, 8 Jan 2020 12:24:13 +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: <6038.1578420793574513591@groups.io>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-MC-Unique: RPenlTLjPqSZN0a3Pz82Nw-1
X-Mimecast-Spam-Score: 0
Content-Language: en-US
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
(+James)
On 01/07/20 19:13, Eugene Khoruzhenko wrote:
> I think I may have found the problem. I can write the
> file_name.signed created by your scripts in NT32 emulated environment
> and in EDKII on Minnow board that I build myself. However, I cannot
> write the file_name.signed on a commercial device. I can write the
> same authenticate variable with the same Name/GUID and same cert/key
> on a device when I create the payload in a UEFI Shell app. So the
> only difference is creating the signed payload by sbvarsign in Ubuntu
> vs doing it in UEFI. I compared both the working and non-working
> payloads and the main difference I see is in the timestamp. For some
> reason sbvarsign writes the Year as 0x0078 (120) vs the UEFI app
> writing 0x07e4 (2020). The month/day/hour/min seems to be OK, but the
> year is really off in the sbvarsign's payload. I cannot prove it, but
> I think the commercial firmware may be having a sanity check for the
> timestamp date/time, e.g. compare with the device manufacture date.
> Since sbvarsign does not allow setting a timestamp separately, I
> cannot force it to create a payload with the correct year.
That looks like a bug in sbvarsign. In UEFI-2.8, the EFI_TIME structure
is defined under 8.3 "Time Services" / GetTime(). The Year field is
given like this:
UINT16 Year; // 1900 - 9999
The comment indicates the valid range. It does not indicate that the
value stored should be relative to the year 1900 (which is what
sbvarsign appears to assume; 2020-1900=120).
The UEFI application likely uses GetTime(), for populating
"EFI_VARIABLE_AUTHENTICATION_2.TimeStamp" with the current time (which
is prescribed in 8.2.2 "Using the EFI_VARIABLE_AUTHENTICATION_2
descriptor").
After GetTime() returns successfully, the application may still need to
manually ensure that "Pad1, Nanosecond, TimeZone, Daylight and Pad2" are
zeroed. This could involve timezone translation (to the required UTC),
which in some cases could even imply a change to the Year field. But
that doesn't change the fact that GetTime() initally places an absolute
year number in the Year field, and not one relative to 1900.
Let me see the "sbsigntool" source code:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git
(Repository URL via
.)
Yup, here's the bug (at current master, that is, commit 0dc3d4b5210d,
"Fix PE/COFF checksum calculation", 2019-07-27):
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/tree/src/sbvarsign.c?id=0dc3d4b5210dae158651d058f7ac68a9f178ae84#n215
Quote:
199 static int set_timestamp(EFI_TIME *timestamp)
200 {
201 struct tm *tm;
202 time_t t;
203
204 time(&t);
205
206 tm = gmtime(&t);
207 if (!tm) {
208 perror("gmtime");
209 return -1;
210 }
211
212 /* copy to our EFI-specific time structure. Other fields (Nanosecond,
213 * TimeZone, Daylight and Pad) are defined to be zero */
214 memset(timestamp, 0, sizeof(*timestamp));
215 timestamp->Year = tm->tm_year;
216 timestamp->Month = tm->tm_mon;
217 timestamp->Day = tm->tm_mday;
218 timestamp->Hour = tm->tm_hour;
219 timestamp->Minute = tm->tm_min;
220 timestamp->Second = tm->tm_sec;
221
222 return 0;
223 }
Please refer to POSIX for time(), gmtime(), and "struct tm":
https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/gmtime.html
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html
Quoting the last reference:
> The header shall declare the tm structure, which shall
> include at least the following members:
>
> int tm_sec Seconds [0,60].
> int tm_min Minutes [0,59].
> int tm_hour Hour [0,23].
> int tm_mday Day of month [1,31].
> int tm_mon Month of year [0,11].
> int tm_year Years since 1900.
> int tm_wday Day of week [0,6] (Sunday =0).
> int tm_yday Day of year [0,365].
> int tm_isdst Daylight Savings flag.
That is, field "tm_year" is relative to 1900.
The bug is therefore in set_timestamp(), on line 215. It should be
timestamp->Year = 1900 + tm->tm_year;
The bug goes back to commit 953b00481f39 ("sbvarsign: First cut of a
variable-signing tool", 2012-08-02).
(Otherwise, gmtime() is a good choice, because it gives us UTC at once,
which is what EFI_VARIABLE_AUTHENTICATION_2 requires, per UEFI spec
("GMT").)
I don't know where sbsigntools development occurs (mailing list, bug
tracker, ...). For now, I'm CC'ing James. (The git repo lives in his
space on .)
James, the original thread on edk2-devel is here:
* [edk2-devel] Interpretation of specification
https://edk2.groups.io/g/devel/message/49402
Thanks,
Laszlo
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143])
by mx.groups.io with SMTP id smtpd.web10.907.1578510822009521288
for ;
Wed, 08 Jan 2020 11:13:43 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=P9uG60p/;
spf=pass (domain: hansenpartnership.com, ip: 66.63.167.143, mailfrom: james.bottomley@hansenpartnership.com)
Received: from localhost (localhost [127.0.0.1])
by bedivere.hansenpartnership.com (Postfix) with ESMTP id D47038EE0CE;
Wed, 8 Jan 2020 11:13:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com;
s=20151216; t=1578510820;
bh=hiFARauoh+OMskOeIk6d2CADRsU2lJmKXHK7S52X3ZU=;
h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
b=P9uG60p/GEJp6YrTxCxtV8xq5RW9TWbFSGPr0npx7NnCWFruFGoKm9BQPhtY4oj9j
FDvOZ6pQ1CCpt6TXjddSY/oiDUMIjo2Hgjj3yrV/BEnsHVW7iDwZHv7wpRHlYE6iuq
zmtBaF/qCl+K4OaQNeQKk7pSPSJBBvgtd8+KWQjg=
Received: from bedivere.hansenpartnership.com ([127.0.0.1])
by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id m8mu0Q_DHKEs; Wed, 8 Jan 2020 11:13:40 -0800 (PST)
Received: from jarvis.lan (unknown [50.35.76.230])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id EEA048EE079;
Wed, 8 Jan 2020 11:13:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com;
s=20151216; t=1578510820;
bh=hiFARauoh+OMskOeIk6d2CADRsU2lJmKXHK7S52X3ZU=;
h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
b=P9uG60p/GEJp6YrTxCxtV8xq5RW9TWbFSGPr0npx7NnCWFruFGoKm9BQPhtY4oj9j
FDvOZ6pQ1CCpt6TXjddSY/oiDUMIjo2Hgjj3yrV/BEnsHVW7iDwZHv7wpRHlYE6iuq
zmtBaF/qCl+K4OaQNeQKk7pSPSJBBvgtd8+KWQjg=
Message-ID: <1578510817.3260.73.camel@HansenPartnership.com>
Subject: Re: [edk2-devel] Interpretation of specification
From: James Bottomley
To: Laszlo Ersek , ekhoruzhenko@absolute.com
Cc: devel@edk2.groups.io, Paulo Henrique Lacerda de Amorim
Date: Wed, 08 Jan 2020 11:13:37 -0800
In-Reply-To:
References:
<6038.1578420793574513591@groups.io>
X-Mailer: Evolution 3.26.6
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
On Wed, 2020-01-08 at 12:24 +0100, Laszlo Ersek wrote:
> (+James)
>
> On 01/07/20 19:13, Eugene Khoruzhenko wrote:
> > I think I may have found the problem. I can write the
> > file_name.signed created by your scripts in NT32 emulated
> > environment and in EDKII on Minnow board that I build myself.
> > However, I cannot write the file_name.signed on a commercial
> > device. I can write the same authenticate variable with the same
> > Name/GUID and same cert/key on a device when I create the payload
> > in a UEFI Shell app. So the only difference is creating the signed
> > payload by sbvarsign in Ubuntu vs doing it in UEFI. I compared both
> > the working and non-working payloads and the main difference I see
> > is in the timestamp. For some reason sbvarsign writes the Year as
> > 0x0078 (120) vs the UEFI app writing 0x07e4 (2020). The
> > month/day/hour/min seems to be OK, but the year is really off in
> > the sbvarsign's payload. I cannot prove it, but I think the
> > commercial firmware may be having a sanity check for the
> > timestamp date/time, e.g. compare with the device manufacture date.
> > Since sbvarsign does not allow setting a timestamp separately, I
> > cannot force it to create a payload with the correct year.
>
> That looks like a bug in sbvarsign. In UEFI-2.8, the EFI_TIME
> structure is defined under 8.3 "Time Services" / GetTime(). The Year
> field is given like this:
>
> UINT16 Year; // 1900 - 9999
>
> The comment indicates the valid range. It does not indicate that the
> value stored should be relative to the year 1900 (which is what
> sbvarsign appears to assume; 2020-1900=120).
>
> The UEFI application likely uses GetTime(), for populating
> "EFI_VARIABLE_AUTHENTICATION_2.TimeStamp" with the current time
> (which is prescribed in 8.2.2 "Using the
> EFI_VARIABLE_AUTHENTICATION_2 descriptor").
>
> After GetTime() returns successfully, the application may still need
> to manually ensure that "Pad1, Nanosecond, TimeZone, Daylight and
> Pad2" are zeroed. This could involve timezone translation (to the
> required UTC), which in some cases could even imply a change to the
> Year field. But that doesn't change the fact that GetTime() initally
> places an absolute year number in the Year field, and not one
> relative to 1900.
>
> Let me see the "sbsigntool" source code:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.gi
> t
>
> (Repository URL via
> .)
>
> Yup, here's the bug (at current master, that is, commit 0dc3d4b5210d,
> "Fix PE/COFF checksum calculation", 2019-07-27):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.gi
> t/tree/src/sbvarsign.c?id=0dc3d4b5210dae158651d058f7ac68a9f178ae84#n2
> 15
>
> Quote:
>
> 199 static int set_timestamp(EFI_TIME *timestamp)
> 200 {
> 201 struct tm *tm;
> 202 time_t t;
> 203
> 204 time(&t);
> 205
> 206 tm = gmtime(&t);
> 207 if (!tm) {
> 208 perror("gmtime");
> 209 return -1;
> 210 }
> 211
> 212 /* copy to our EFI-specific time structure. Other
> fields (Nanosecond,
> 213 * TimeZone, Daylight and Pad) are defined to be zero
> */
> 214 memset(timestamp, 0, sizeof(*timestamp));
> 215 timestamp->Year = tm->tm_year;
> 216 timestamp->Month = tm->tm_mon;
> 217 timestamp->Day = tm->tm_mday;
> 218 timestamp->Hour = tm->tm_hour;
> 219 timestamp->Minute = tm->tm_min;
> 220 timestamp->Second = tm->tm_sec;
> 221
> 222 return 0;
> 223 }
>
> Please refer to POSIX for time(), gmtime(), and "struct tm":
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.htm
> l
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/gmtime.h
> tml
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.ht
> ml
>
> Quoting the last reference:
>
> > The header shall declare the tm structure, which shall
> > include at least the following members:
> >
> > int tm_sec Seconds [0,60].
> > int tm_min Minutes [0,59].
> > int tm_hour Hour [0,23].
> > int tm_mday Day of month [1,31].
> > int tm_mon Month of year [0,11].
> > int tm_year Years since 1900.
> > int tm_wday Day of week [0,6] (Sunday =0).
> > int tm_yday Day of year [0,365].
> > int tm_isdst Daylight Savings flag.
>
> That is, field "tm_year" is relative to 1900.
>
> The bug is therefore in set_timestamp(), on line 215. It should be
>
> timestamp->Year = 1900 + tm->tm_year;
>
> The bug goes back to commit 953b00481f39 ("sbvarsign: First cut of a
> variable-signing tool", 2012-08-02).
>
> (Otherwise, gmtime() is a good choice, because it gives us UTC at
> once, which is what EFI_VARIABLE_AUTHENTICATION_2 requires, per UEFI
> spec ("GMT").)
>
> I don't know where sbsigntools development occurs (mailing list, bug
> tracker, ...). For now, I'm CC'ing James. (The git repo lives in his
> space on .)
Heh, that's a sore point: since Jeremy Kerr left ubuntu, no-one except
me has been maintaining it; Jeremy owns the original tree on the Ubuntu
servers but can't update it any more.
I use groups.io for the openssl_tpm2_engine development list, so I
suppose I can set one up for sbsigntools ... OK, done. If you want to
you can package the above up as a patch and send it there and I'll
apply it.
James
> James, the original thread on edk2-devel is here:
>
> * [edk2-devel] Interpretation of specification
> https://edk2.groups.io/g/devel/message/49402
>
> Thanks,
> Laszlo
>
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120])
by mx.groups.io with SMTP id smtpd.web10.11797.1578590247699243085
for ;
Thu, 09 Jan 2020 09:17:27 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GgueHBQH;
spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1578590246;
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=5o2XjikM78jCGvom6ueMbaGZRPNgwxVD+9xNCvv3GfU=;
b=GgueHBQHD2s+qVIGGXQbk7Jg+YPU/QXDr4PkJG9uA+tRL8YfLO7b4GswbCcTmgYKPqbNkf
lrXvh535S+Xt5MIpMxizp6ierFnCjAKd/8cI5+EqHgArMDss5fVl21u7O0/Fm2pMTtGS/+
vfcXAwWoeWJ6Ub75h1QFyGIb5CmezQc=
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-283-FQfwWqOqMUGXhyCBRKdQyQ-1; Thu, 09 Jan 2020 12:17:19 -0500
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 87B538024D5;
Thu, 9 Jan 2020 17:17:18 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.145])
by smtp.corp.redhat.com (Postfix) with ESMTP id 837EA5DA32;
Thu, 9 Jan 2020 17:17:17 +0000 (UTC)
Subject: Re: [edk2-devel] Interpretation of specification
To: James Bottomley
Cc: ekhoruzhenko@absolute.com, devel@edk2.groups.io,
Paulo Henrique Lacerda de Amorim
References:
<6038.1578420793574513591@groups.io>
<1578510817.3260.73.camel@HansenPartnership.com>
From: "Laszlo Ersek"
Message-ID: <0353cfad-68cf-d5c6-3f36-b57e3bc6ff0a@redhat.com>
Date: Thu, 9 Jan 2020 18:17:16 +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: <1578510817.3260.73.camel@HansenPartnership.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-MC-Unique: FQfwWqOqMUGXhyCBRKdQyQ-1
X-Mimecast-Spam-Score: 0
Content-Language: en-US
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hello James,
On 01/08/20 20:13, James Bottomley wrote:
> On Wed, 2020-01-08 at 12:24 +0100, Laszlo Ersek wrote:
>> I don't know where sbsigntools development occurs (mailing list, bug
>> tracker, ...). For now, I'm CC'ing James. (The git repo lives in his
>> space on .)
>
> Heh, that's a sore point: since Jeremy Kerr left ubuntu, no-one except
> me has been maintaining it; Jeremy owns the original tree on the Ubuntu
> servers but can't update it any more.
>
> I use groups.io for the openssl_tpm2_engine development list, so I
> suppose I can set one up for sbsigntools ... OK, done. If you want to
> you can package the above up as a patch and send it there and I'll
> apply it.
I've now posted:
[PATCH] sbvarsign: fix "EFI_VARIABLE_AUTHENTICATION_2.TimeStamp.Year" assignment
Message-Id: <20200109171302.28782-1-lersek@redhat.com>
to .
I didn't (and most likely, won't) subscribe to that list, so please whitelist this individual posting of mine, on the admin interface.
Thanks!
Laszlo
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143])
by mx.groups.io with SMTP id smtpd.web09.11980.1578590429522512320
for ;
Thu, 09 Jan 2020 09:20:30 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=YBWVlTA2;
spf=pass (domain: hansenpartnership.com, ip: 66.63.167.143, mailfrom: james.bottomley@hansenpartnership.com)
Received: from localhost (localhost [127.0.0.1])
by bedivere.hansenpartnership.com (Postfix) with ESMTP id 10BDF8EE0FC;
Thu, 9 Jan 2020 09:20:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com;
s=20151216; t=1578590428;
bh=voHB7dAi/b2Pj71CwXiymAO5TsN6wPAvZBzJs8eMsOA=;
h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
b=YBWVlTA2bNBkP5fdrqQr0fwpUmqxxHuPyQt1DkONcLsEuzmUmUONQJY7Kb1+VK7Zi
iyg9CYP8uZYLBmyRU2B1oegOeNBF/HrGzH8qd1oqm4PFmIfq5CR99sw6y5p34p4Jtu
UugPdqbcUuLpTgxo/t7Lx4nuxQqqGfIhRB3JCy9M=
Received: from bedivere.hansenpartnership.com ([127.0.0.1])
by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2Q_2el7w2RbY; Thu, 9 Jan 2020 09:20:26 -0800 (PST)
Received: from jarvis.lan (unknown [50.35.76.230])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 7D2A48EE056;
Thu, 9 Jan 2020 09:20:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com;
s=20151216; t=1578590426;
bh=voHB7dAi/b2Pj71CwXiymAO5TsN6wPAvZBzJs8eMsOA=;
h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
b=o94mmGl2k97Ql+4fYHO33A81SCg1QenwrojWq+/tghRmPhsmyH/GQa3OuoXni8Iwm
mVp1bz/YAJ4ktMUpduO38N/SuagzM1OvCGXJFBrwRIurBnzU+ugyU65MPC7epSWI/x
+SwvIxFyC3lAdHg3Y4NLN9zNr6C0pN5yd28fsFU0=
Message-ID: <1578590422.3526.6.camel@HansenPartnership.com>
Subject: Re: [edk2-devel] Interpretation of specification
From: James Bottomley
To: Laszlo Ersek
Cc: ekhoruzhenko@absolute.com, devel@edk2.groups.io, Paulo Henrique Lacerda
de Amorim
Date: Thu, 09 Jan 2020 09:20:22 -0800
In-Reply-To: <0353cfad-68cf-d5c6-3f36-b57e3bc6ff0a@redhat.com>
References:
<6038.1578420793574513591@groups.io>
<1578510817.3260.73.camel@HansenPartnership.com>
<0353cfad-68cf-d5c6-3f36-b57e3bc6ff0a@redhat.com>
X-Mailer: Evolution 3.26.6
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
On Thu, 2020-01-09 at 18:17 +0100, Laszlo Ersek wrote:
> Hello James,
>
> On 01/08/20 20:13, James Bottomley wrote:
> > On Wed, 2020-01-08 at 12:24 +0100, Laszlo Ersek wrote:
> > > I don't know where sbsigntools development occurs (mailing list,
> > > bug
> > > tracker, ...). For now, I'm CC'ing James. (The git repo lives in
> > > his
> > > space on .)
> >
> > Heh, that's a sore point: since Jeremy Kerr left ubuntu, no-one
> > except
> > me has been maintaining it; Jeremy owns the original tree on the
> > Ubuntu
> > servers but can't update it any more.
> >
> > I use groups.io for the openssl_tpm2_engine development list, so I
> > suppose I can set one up for sbsigntools ... OK, done. If you want
> > to
> > you can package the above up as a patch and send it there and I'll
> > apply it.
>
> I've now posted:
>
> [PATCH] sbvarsign: fix
> "EFI_VARIABLE_AUTHENTICATION_2.TimeStamp.Year" assignment
> Message-Id: <20200109171302.28782-1-lersek@redhat.com>
>
> to .
>
> I didn't (and most likely, won't) subscribe to that list, so please
> whitelist this individual posting of mine, on the s.groups.io> admin interface.
Heh, trying to dust off the groups.io setup memories as we speak. I
can't allow fully unmoderated postings, unfortunately. I also think
the group rejected this out of hand because it's not in the moderation
queue, but I think I've found the flag that holds non-member posts for
moderation and thus allows them to be posted instead of rejected.
James
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81])
by mx.groups.io with SMTP id smtpd.web12.8399.1578653716792033864
for ;
Fri, 10 Jan 2020 02:55:17 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aCFo1wtc;
spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1578653715;
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=9AcY8xzMRIr0dBqnLMi/YG9/d1UYLyb+J4NR0+BSh9A=;
b=aCFo1wtctwur+IzBolEC8YIy/60M2jmkUvt6mzC9dwBAnlSe9B5Ax8tRcURXVXn9ixE8YM
2O6TZPTeroQWqhf2X7/+oFoXBqdDLF/TajDbBd7fU8ANWD2ug/8NCoV0AJRB9r++oOgeRt
Rfq/vGOhWdtOZ0I3+hBjkQXa30iTIvQ=
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-11-5gvbCzxDM6-Zrz5IMg-www-1; Fri, 10 Jan 2020 05:55:06 -0500
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 81F3D18A6EC0;
Fri, 10 Jan 2020 10:55:05 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-179.ams2.redhat.com [10.36.116.179])
by smtp.corp.redhat.com (Postfix) with ESMTP id 751BE7C015;
Fri, 10 Jan 2020 10:55:04 +0000 (UTC)
Subject: Re: [edk2-devel] Interpretation of specification
To: devel@edk2.groups.io, James.Bottomley@HansenPartnership.com
Cc: ekhoruzhenko@absolute.com,
Paulo Henrique Lacerda de Amorim
References:
<6038.1578420793574513591@groups.io>
<1578510817.3260.73.camel@HansenPartnership.com>
<0353cfad-68cf-d5c6-3f36-b57e3bc6ff0a@redhat.com>
<1578590422.3526.6.camel@HansenPartnership.com>
From: "Laszlo Ersek"
Message-ID:
Date: Fri, 10 Jan 2020 11:55:03 +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: <1578590422.3526.6.camel@HansenPartnership.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-MC-Unique: 5gvbCzxDM6-Zrz5IMg-www-1
X-Mimecast-Spam-Score: 0
Content-Language: en-US
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
On 01/09/20 18:20, James Bottomley wrote:
> On Thu, 2020-01-09 at 18:17 +0100, Laszlo Ersek wrote:
>> Hello James,
>>
>> On 01/08/20 20:13, James Bottomley wrote:
>>> On Wed, 2020-01-08 at 12:24 +0100, Laszlo Ersek wrote:
>>>> I don't know where sbsigntools development occurs (mailing list,
>>>> bug
>>>> tracker, ...). For now, I'm CC'ing James. (The git repo lives in
>>>> his
>>>> space on .)
>>>
>>> Heh, that's a sore point: since Jeremy Kerr left ubuntu, no-one
>>> except
>>> me has been maintaining it; Jeremy owns the original tree on the
>>> Ubuntu
>>> servers but can't update it any more.
>>>
>>> I use groups.io for the openssl_tpm2_engine development list, so I
>>> suppose I can set one up for sbsigntools ... OK, done. If you want
>>> to
>>> you can package the above up as a patch and send it there and I'll
>>> apply it.
>>
>> I've now posted:
>>
>> [PATCH] sbvarsign: fix
>> "EFI_VARIABLE_AUTHENTICATION_2.TimeStamp.Year" assignment
>> Message-Id: <20200109171302.28782-1-lersek@redhat.com>
>>
>> to .
>>
>> I didn't (and most likely, won't) subscribe to that list, so please
>> whitelist this individual posting of mine, on the > s.groups.io> admin interface.
>
> Heh, trying to dust off the groups.io setup memories as we speak. I
> can't allow fully unmoderated postings, unfortunately.
Right, that's my understanding too -- fully open lists are not supported
on groups.io (and at least in the edk2 community, most participants
don't like fully open posting -- I happen to be a fan of open posting,
FWIW). Worse, for non-subscribers, the best that groups.io offers is
white-listing per *message*, and not per *sender*.
> I also think
> the group rejected this out of hand because it's not in the moderation
> queue, but I think I've found the flag that holds non-member posts for
> moderation and thus allows them to be posted instead of rejected.
Ugh, I didn't know that just holding messages for moderation took a
separate setting!
Thanks!
Laszlo
From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143])
by mx.groups.io with SMTP id smtpd.web09.12290.1578672284425719561
for ;
Fri, 10 Jan 2020 08:04:44 -0800
Authentication-Results: mx.groups.io;
dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=aUq8FhDE;
spf=pass (domain: hansenpartnership.com, ip: 66.63.167.143, mailfrom: james.bottomley@hansenpartnership.com)
Received: from localhost (localhost [127.0.0.1])
by bedivere.hansenpartnership.com (Postfix) with ESMTP id 8D9C08EE0F5;
Fri, 10 Jan 2020 08:04:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com;
s=20151216; t=1578672280;
bh=K2mfvNb1M7JAlsdXvg0PokIsH7H8Qx4qLzbYoWPAlkI=;
h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
b=aUq8FhDEZgTaN8VNfpNca5n+hsmGk3ujRxUujJHRaU2dVkPUogCetun4Lxd3y5gAL
bzPEXVKgo1gmGo+7MMVJ1lu0iUgCd9e4z4Jpo40AFmAzw/6gQbEizhh1WFMlWx3j8U
a5AguzyqQ5yWzQtolcNz4XBm9Y8NYQbwA2c8Ad7k=
Received: from bedivere.hansenpartnership.com ([127.0.0.1])
by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3RediQul42iP; Fri, 10 Jan 2020 08:04:27 -0800 (PST)
Received: from jarvis.lan (unknown [50.35.76.230])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 4AFFF8EE0D2;
Fri, 10 Jan 2020 08:04:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com;
s=20151216; t=1578672262;
bh=K2mfvNb1M7JAlsdXvg0PokIsH7H8Qx4qLzbYoWPAlkI=;
h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
b=Q+4c+ZAWkeJwz+lQ1OBk3EhvMpGFh/I1yUwJ16rmxou50AGC/4cSthHFwnpYGgF30
iTeHuEWe0dHys8JPm+J5O+rHRWUW7r8b+ak4idFPJFdxZR8K4HeASM5eTw9Tpix0Yc
BsitbLzKL5HTHmT1pd95pa24+tNdlo8rOt1QEYNc=
Message-ID: <1578672256.3012.6.camel@HansenPartnership.com>
Subject: Re: [edk2-devel] Interpretation of specification
From: James Bottomley
To: Laszlo Ersek , devel@edk2.groups.io
Cc: ekhoruzhenko@absolute.com, Paulo Henrique Lacerda de Amorim
Date: Fri, 10 Jan 2020 08:04:16 -0800
In-Reply-To:
References:
<6038.1578420793574513591@groups.io>
<1578510817.3260.73.camel@HansenPartnership.com>
<0353cfad-68cf-d5c6-3f36-b57e3bc6ff0a@redhat.com>
<1578590422.3526.6.camel@HansenPartnership.com>
X-Mailer: Evolution 3.26.6
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
On Fri, 2020-01-10 at 11:55 +0100, Laszlo Ersek wrote:
> Right, that's my understanding too -- fully open lists are not
> supported on groups.io (and at least in the edk2 community, most
> participants don't like fully open posting -- I happen to be a fan of
> open posting, FWIW). Worse, for non-subscribers, the best that
> groups.io offers is white-listing per *message*, and not per
> *sender*.
Yes, that's the most annoying feature of groups.io
It can be worked around though: I've got an auto-reply on the moderator
email using procmail that auto-approves every message held for
moderation ... although I'm not sure that would work well on a higher
traffic list.
> > I also think the group rejected this out of hand because it's not
> > in the moderation queue, but I think I've found the flag that holds
> > non-member posts for moderation and thus allows them to be posted
> > instead of rejected.
>
> Ugh, I didn't know that just holding messages for moderation took a
> separate setting!
Yes, apparently ... I remember having the same trouble with the
openssl-tpm2-engine group.
James