public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, phlamorim@riseup.net
Subject: Re: [edk2-devel] Interpretation of specification
Date: Thu, 24 Oct 2019 14:33:08 +0200	[thread overview]
Message-ID: <748ab441-35e4-31d2-1d94-be2a3c4752c8@redhat.com> (raw)
In-Reply-To: <30436.1571850762845158639@groups.io>

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


  reply	other threads:[~2019-10-24 12:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 17:12 Interpretation of specification phlamorim
2019-10-24 12:33 ` Laszlo Ersek [this message]
2019-11-15 18:51   ` [edk2-devel] " phlamorim
2019-11-15 21:32     ` Laszlo Ersek
2019-11-23  4:59     ` Eugene Khoruzhenko
2019-11-23 13:08       ` Paulo Henrique Lacerda de Amorim
2019-11-26  6:08         ` Eugene Khoruzhenko
2019-11-26 15:22           ` Paulo Henrique Lacerda de Amorim
2020-01-03 19:52             ` Eugene Khoruzhenko
2020-01-04 17:17               ` Paulo Henrique Lacerda de Amorim
2020-01-07 18:13                 ` Eugene Khoruzhenko
2020-01-08 11:24                   ` Laszlo Ersek
2020-01-08 19:13                     ` James Bottomley
2020-01-09 17:17                       ` Laszlo Ersek
2020-01-09 17:20                         ` James Bottomley
2020-01-10 10:55                           ` Laszlo Ersek
2020-01-10 16:04                             ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=748ab441-35e4-31d2-1d94-be2a3c4752c8@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox