From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.3128.1675504710184323265 for ; Sat, 04 Feb 2023 01:58:31 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=VG42Fn5J; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9693E240379 for ; Sat, 4 Feb 2023 10:58:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1675504707; bh=HVtuQqfmFdud7u634OGTQtGQlyeSYzO70rj24qaiiO4=; h=From:Subject:Date:Cc:To:From; b=VG42Fn5J0ynOZtNpvu6R7dW5fRoDzkkwot+smUCwZ8Q7JxPAMk7YD137eeZlvpSmC ny9xS4j6wCNgrfvE3R1rCiZPrBFYMejsclFTdw/9uHMLjcQ6JXPBpiZ8LWAY1L9zrh eZGztTXf6UFY0MTOBIIq2AZ+7EBM9GC3haCvT98p0ZOWC4U4sXGTxZHbpxQiJBPdAg Adt+IMWwAcCd1wC/jfOBi0OEqTdpaFCrajQrPkanD3Iiu3WGV/NCVRWDCBpUmKyBAJ 6gKKZE1t/sWWNLsGsHKwGbDZhjvOyqufgtx/BPPiiAwegMX1BNucIcll923RFNwyCE UaqKxKG25039A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P87JL4FQVz6tn5; Sat, 4 Feb 2023 10:58:26 +0100 (CET) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Mime-Version: 1.0 (1.0) Subject: Re: [edk2-devel] [PATCH 00/11] OvmfPkg: add Crypto Driver support Date: Sat, 4 Feb 2023 09:58:26 +0000 Message-Id: References: Cc: devel@edk2.groups.io, Pedro Falcato In-Reply-To: To: Ard Biesheuvel Content-Type: multipart/alternative; boundary=Apple-Mail-6B5C7EC7-0037-4C75-9E19-9EA4E7D35ABB Content-Transfer-Encoding: 7bit --Apple-Mail-6B5C7EC7-0037-4C75-9E19-9EA4E7D35ABB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 4. Feb 2023, at 09:05, Ard Biesheuvel wrote: >=20 > =EF=BB=BFOn Sat, 4 Feb 2023 at 02:13, Marvin H=C3=A4user wrote: >>=20 >> Hi Ard, >>=20 >> While I agree the tone is a bit irritating, I am not sure what kind of co= ntext you expect there to be. The library is nearing EOL and usage beyond EO= L is unacceptable. It will take significant time to solve the related issues= , test them, have them merged, and for them to trickle down the IBV chains. >>=20 >> OpenSSL is quite "big" in general and many consider it to not be a good c= hoice for embedded usage. Do you know of any discussion regarding alternativ= es? I've heard folks use libsodium or mbedtls outside edk2, but don't have a= ny experience with either. (Not necessarily looking to *start* a discussion,= but mostly references / reading material, if you have any.) >>=20 >=20 > Again, I don't have the full context here, so with that in mind: >=20 > Open source is about the freedom to use the code base in any way you > like. This is a point that can trivially be driven ad absurdum, so I=E2=80=99ll no= t press further. I think everyone agrees to *an extent* and *nobody* will ag= ree to the full extent. > Surely, Intel (as a collaborator in Tianocore) is entitled to > express a desire to retain the OpenSSL 1.1 version of CryptoPkg as an > option while we move it to OpenSSL 3? It is not even important how > they actually intend to use it, that is really their business. >=20 > Of course, if you *buy* from Intel, you have all reason to be annoyed > if their products are based on outdated crypto software. But that > doesn't mean it is up to the community to take away their ability to > do so. Not if they drive the deprecation at a reasonable schedule. Regarding which,= just in: https://edk2.groups.io/g/devel/message/99638 *Thank you*, Jiewen! >=20 > Most Intel based consumer products don't have firmware that is > supplied by Intel directly, and the IBVs have their own forks anyway, > so it is not even clear to me who would be affected by this. In my experience, things like security get little attention and thus, at lea= st at first, forks will use whatever upstream uses. :( >=20 > As for the use of mbetls or other [better] TLS libraries: I'd be all > for that, but I'm not sure how much work those libraries need to be > usable in the context of EDK2. IIRC, some changes went upstream into > OpenSSL for the UEFI execution context, and we'd probably need to do > the same for mbedtls. Not so sure, the big issue with OpenSSL is its embedded-unfriendly design. T= he biggest reason I could think of would be the ConvertPointer() theatre. I k= now for a fact that some folks use mbedtls even for UEFI purposes, but not w= hether that=E2=80=99s for RT code. It=E2=80=99s all closed source, so=E2=80=A6= :( Best regards, Marvin= --Apple-Mail-6B5C7EC7-0037-4C75-9E19-9EA4E7D35ABB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 4. Feb 2023, at 09:05, A= rd Biesheuvel <ardb@kernel.org> wrote:

=EF=BB=BFOn Sat, 4 Feb 2023 at 0= 2:13, Marvin H=C3=A4user <mhaeuser@posteo.de> wrote:

<= span>Hi Ard,
<= br>
While I agree the tone is a b= it irritating, I am not sure what kind of context you expect there to be. Th= e library is nearing EOL and usage beyond EOL is unacceptable. It will take s= ignificant time to solve the related issues, test them, have them merged, an= d for them to trickle down the IBV chains.

OpenSSL is quite "big" in general and many consider it to not be a good ch= oice for embedded usage. Do you know of any discussion regarding alternative= s? I've heard folks use libsodium or mbedtls outside edk2, but don't have an= y experience with either. (Not necessarily looking to *start* a discussion, b= ut mostly references / reading material, if you have any.)

<= br>Again, I don't have the full context here, so with that in mind:

Open source is about the freedom to use the c= ode base in any way you
like.
=
This is a point that can trivially be driven ad absurdum, so I= =E2=80=99ll not press further. I think everyone agrees to *an extent* and *n= obody* will agree to the full extent.

Surely, Intel (as a collaborator in Tianocore) is entitl= ed to
express a desire to retain the OpenSSL 1.1 version of C= ryptoPkg as an
option while we move it to OpenSSL 3? It is n= ot even important how
they actually intend to use it, that i= s really their business.

Of course, if you *= buy* from Intel, you have all reason to be annoyed
if their p= roducts are based on outdated crypto software. But that
does= n't mean it is up to the community to take away their ability to
<= span>do so.

Not if they dri= ve the deprecation at a reasonable schedule. Regarding which, just in: = https://edk2.groups= .io/g/devel/message/99638
*Thank you*, Jiewen!


Most Intel based= consumer products don't have firmware that is
supplied by I= ntel directly, and the IBVs have their own forks anyway,
so i= t is not even clear to me who would be affected by this.

In my experience, things like security get lit= tle attention and thus, at least at first, forks will use whatever upstream u= ses. :(

As for the use of mbetls or other [better] TLS libraries: I'd be all<= /span>
for that, but I'm not sure how much work those libraries nee= d to be
usable in the context of EDK2. IIRC, some changes we= nt upstream into
OpenSSL for the UEFI execution context, and= we'd probably need to do
the same for mbedtls.

Not so sure, the big issue with OpenSSL is its emb= edded-unfriendly design. The biggest reason I could think of would be the Co= nvertPointer() theatre. I know for a fact that some folks use mbedtls even f= or UEFI purposes, but not whether that=E2=80=99s for RT code. It=E2=80=99s a= ll closed source, so=E2=80=A6 :(

Best regards,
Marvin
= --Apple-Mail-6B5C7EC7-0037-4C75-9E19-9EA4E7D35ABB--