Re: [edk2-devel] [PATCH 00/11] OvmfPkg: add Crypto Driver support

["Pedro Falcato" <pedro.falcato@gmail.com>]

On Fri, Feb 3, 2023 at 11:25 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 3 Feb 2023 at 20:45, Pedro Falcato <pedro.falcato@gmail.com> wrote:
> >
> > On Fri, Feb 3, 2023 at 4:28 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >
> > >   Hi,
> > >
> > > > > Unfortunately it is not a clear size win everywhere.
> > > > >
> > > > > PEI jumps up in size even though I'm using the min_pei config for
> > > > > CryptoPei, seems it *still* has way too much bits compiled in
> > > > > (didn't look into tweaking the config yet, hints are welcome).
> > > > >
> > > > > -   17530 TcgPei
> > > > > +   17146 TcgPei
> > > > > +   34362 Tcg2Pei
> > > > > -   51066 Tcg2Pei
> > > > > +  333950 CryptoPei
> > > >
> > > > Why would we use this for PEI if the size increases?
> > >
> > > When using the crypto driver I'd prefer to do it everywhere and
> > > don't mix+match things.
> > >
> > > Background is that I'm hoping the crypto driver abstraction can also
> > > help to have alternative drivers using other crypto libraries without
> > > creating a huge mess in CryptoPkg.  Specifically add openssl-3 as an
> > > option.  openssl-11 goes EOL later this year (Nov IIRC).  Switch to
> > > openssl-3 unconditionally has been vetoed by Intel due to the size
> > > increase v3 brings.  So I'm looking for options here ...
> >
> > Seriously?
> >
> > Intel is blocking UP TO DATE NOT VULNERABLE OPENSSL because it doesn't
> > fit their flash due to all the cra- value add?
> > This is insane by many standards. Your freaking *CRYPTO LIBRARY* goes
> > EOL and people are still concerned about size.
> >
> > Stellar job, Intel. Hopefully everyone gets their horrific custom
> > network stack heartbled to death. Or someone finds yet another Secure
> > Boot exploit.
> >
>
> This is uncalled for. Please keep it civil and on topic. You (nor I)
> have any context about this, and if you want to start a shouting match
> on a public mailing list, I suggest you first get informed about what
> the actual reasoning is behind such a decision (which, according to
> the above, is the decision to keep OpenSSL 1.1 and 3 available side by
> side). And please start another thread for this - I have no interest
> in being part of this type of discussion.

Sorry everyone, that was a ...passionate speech.
I recognize I'm on the wrong here.

Vendors and CryptoPkg people, please consider upgrading to OpenSSL 3.
1.1 is going EOL and security
for crypto related activities (especially for a project like OpenSSL
with such a CVE-full life) should be paramount.
Surely there are other ways you can cut on flash space.

</discussion>

As for the patches themselves, big +1 if they help decouple TLS
libraries. I've been thinking about trying another TLS lib
like mbedtls ever since the problems with OpenSSL and compiler
intrinsics came along, some time ago. Probably smaller too.

-- 
Pedro