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.web09.3748.1571920396365292928 for ; Thu, 24 Oct 2019 05:33:16 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WM6YkOPi; 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=1571920395; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nQ+gTDlyCbbLV0UIw3r8w7iH+1iQjJTx3jifN6cP1II=; b=WM6YkOPiL74xv4fm6v54aKwRPr7VF5YzYW93HxVhSMpvy9W1zjqwBwF3k4p7tvoD3gAPxQ uz8xl7S1Lks2nvMUKU1SlcWPztJ0tltzZMnJvqJXXvoC+JV1G4hy3IpZQTJuUXsbQb3kTf DRQDh/1RbOrs6iBRa/E/hAi21cgwiZM= 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-62-FnM8n-RtNSunyedWd3mNVQ-1; Thu, 24 Oct 2019 08:33:11 -0400 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 25F541005500; Thu, 24 Oct 2019 12:33:10 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.161]) by smtp.corp.redhat.com (Postfix) with ESMTP id 856035DC1E; Thu, 24 Oct 2019 12:33:09 +0000 (UTC) Subject: Re: [edk2-devel] Interpretation of specification To: devel@edk2.groups.io, phlamorim@riseup.net References: <30436.1571850762845158639@groups.io> From: "Laszlo Ersek" Message-ID: <748ab441-35e4-31d2-1d94-be2a3c4752c8@redhat.com> Date: Thu, 24 Oct 2019 14:33:08 +0200 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: <30436.1571850762845158639@groups.io> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: FnM8n-RtNSunyedWd3mNVQ-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/23/19 19:12, phlamorim@riseup.net wrote: > The following commit on edk2 added a new a check on format of Authenticat= ed variables: https://github.com/tianocore/edk2/commit/c035e37335ae43229d7e= 68de74a65f2c01ebc0af ( https://github.com/tianocore/edk2/commit/c035e37335a= e43229d7e68de74a65f2c01ebc0af ) >=20 > After this point some implementations started to have differences in the = validation of the format of Authenticator Descriptor as we can se here: htt= ps://blog.hansenpartnership.com/uefi-secure-boot/#comment-48351 >=20 > This case make me reach the following discussions: https://bugzilla.tiano= core.org/show_bug.cgi?id=3D586 where i have seen lots of tools(more on linu= x) dont generate the correct format to use on the payload for TimeBased aut= henticated variables, at this time i was just trying to create a private au= thenticated 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/ ) >=20 > But this patch never got merged, so i realized the tools on linux receive= d 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 m= y question is, where the developers should trust to consume the UEFI APIs i= n a trusted way. Another example i had is the path separator "\" or "/", ed= k2 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 sh= ould work on all other implementations too, and how we will try to remove t= hese 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