From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by mx.groups.io with SMTP id smtpd.web10.181.1637260857943393563 for ; Thu, 18 Nov 2021 10:40:58 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=NBEF8keU; spf=pass (domain: gmail.com, ip: 209.85.166.169, mailfrom: vineel.kovvuri@gmail.com) Received: by mail-il1-f169.google.com with SMTP id x9so7516558ilu.6 for ; Thu, 18 Nov 2021 10:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o7eUI4fDwi5nALJg5lHSk1J7G0DR/6MSbO0eBxueXvA=; b=NBEF8keUBrjtEy+SGnO3lGoZBshBrS7UXG48pwCuPeSr0p+Rg3JExiQ0leZIHYSAhg f5C/cWGUFc//yakK+3yJXch1iB1pbFoYoyv2mOeYssVX4SalDczJKWId/SUJi7fS771B aPlkYBg7qkT6tZDwVcml5jWn8TiAVhcK7UzUctwKpo7L+u9Vtra8+tWn5hCXNzBw+EUt UsiObz3vZR+DwaeEDCF5zwwYhQGc4Wk6zY3aRt+rC5ebibm4XPJcwiLXbucXjfDn0wJl +m4q/bKmgBS3YixxV3ac01JSYXk0QIVhZpqSm56MhCpqrzLpNMWdufcTO6wrqOhkhW7Y Wemg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o7eUI4fDwi5nALJg5lHSk1J7G0DR/6MSbO0eBxueXvA=; b=BBMYNe/1A69Zt14fAtgSrCpGMB3vml2jqykyLnehTGtEwGb/W6Uh20tlBcDwqqPns4 p/3hJIRjjNAJEJ/Im32y0nOB2qMAZCtfCgpkGxs/HVxbifw6Si7qLQJPq7NJ2O74dXmF SVdKFrf/Qt5vPPkBAWBt1ljrFiRh7pOAZIC16m1Rkh0nO5KWk0K5NGaUPIVqcBI+gDKq ptVK6VJODwla3eNSvsTRTnjT8JJp9KCif3mTiYXu8spgf1W3mzDpX5amp7TKfmegu7wl jsQYgzayrjbIzmFUKbEEkHSEIz0y6NUS/tAakvYWDUtKwXXzKCamyaP1bE7Kysgy7blU mYJA== X-Gm-Message-State: AOAM530mNFZMLJKrbOTXo84BD8l3sULdU+GdEiNNnleJaX3F8KMOShXG qA8WZjBpm2AwiVuH6xmD5gjbTWQhhooFdym3XRE= X-Google-Smtp-Source: ABdhPJwJjtTe88/FI2mzXCwimrWF7gGU1rDt+LqSqHRfMJvqxbuZjRmpapDQsYUPeq4yoDZ+wl1xG2xC84c5FA5pkrE= X-Received: by 2002:a92:c846:: with SMTP id b6mr788262ilq.255.1637260857457; Thu, 18 Nov 2021 10:40:57 -0800 (PST) MIME-Version: 1.0 References: <23891.1636410576311055186@groups.io> <20211109085809.22kqmzd6zxu465ua@sirius.home.kraxel.org> <20211111130552.qo5a33ki7ikipqpf@sirius.home.kraxel.org> In-Reply-To: From: Vineel Kovvuri Date: Thu, 18 Nov 2021 10:40:46 -0800 Message-ID: Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms To: "Yao, Jiewen" , harshit.n.g@intel.com Cc: Gerd Hoffmann , "devel@edk2.groups.io" , "vineelko@microsoft.com" Content-Type: multipart/alternative; boundary="000000000000d040b505d1147f6a" --000000000000d040b505d1147f6a Content-Type: text/plain; charset="UTF-8" Hi Folks, Sorry for the delay in my response. Thanks for the inputs. My bad for not understanding what Jiewen was referring to, I think he is suggesting to remove the unused algorithms with in the ECC cipher. Not removing already available ciphers. Totally makes sense but it would involve more testing against each private bios with the narrowed list of algorithms. +Harshit from Intel for context Thanks, Vineel On Thu, Nov 11, 2021 at 5:26 AM Yao, Jiewen wrote: > Sorry, I don't mean: one platform uses 2 different configuration. > > That might be worse, because we lose the benefit on compression. > Ideally, no matter how many *same* copies you have, the compression algo > will handle it and make only *one* copy. If you have two *different* > copies, then compression also may finally make *two* different copy. > I don't have data. I just feel it might be worse. > > I mean two platform can choose 2 different configuration. But eventually, > one platform should select one of them consistently, such as using only one > CryptoDxe.inf. > > In this case, you need carefully remove all unneeded algo. > For example, do you really need SM2 ? > Do you really need EdDSA ? > Do you really need ECX ? > > Thank you > Yao Jiewen > > > > -----Original Message----- > > From: Gerd Hoffmann > > Sent: Thursday, November 11, 2021 9:06 PM > > To: Vineel Kovvuri > > Cc: devel@edk2.groups.io; Yao, Jiewen ; > > vineelko@microsoft.com > > Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add > elliptic > > curve chipher algorithms > > > > Hi, > > > > > The difference I see without ecc change and with the change is the > increase > > > in file sizes for below ffs files,(other .ffs files remained unchanged) > > > > > > Without ecc change: > > > 794742 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F80697E9- > > 7FD6-4665-8646-88E33EF71DFCSecurityStubDxe/F80697E9-7FD6-4665-8646- > > 88E33EF71DFC.ffs > > > 653470 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F0E6A44F- > > 7195-41c3-AC64-54F202CD0A21SecureBootConfigDxe/F0E6A44F-7195-41c3- > > AC64-54F202CD0A21.ffs > > > 1174654 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/3aceb0c0- > > 3c72-11e4-9a56-74d435052646TlsDxe/3aceb0c0-3c72-11e4-9a56- > > 74d435052646.ffs > > > 872594 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/23A089B3- > > EED5-4ac5-B2AB-43E3298C2343VariableSmm/23A089B3-EED5-4ac5-B2AB- > > 43E3298C2343.ffs > > > > > > With ecc change: > > > 1058678 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F80697E9- > > 7FD6-4665-8646-88E33EF71DFCSecurityStubDxe/F80697E9-7FD6-4665-8646- > > 88E33EF71DFC.ffs > > > 917214 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F0E6A44F- > > 7195-41c3-AC64-54F202CD0A21SecureBootConfigDxe/F0E6A44F-7195-41c3- > > AC64-54F202CD0A21.ffs > > > 1470718 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/3aceb0c0- > > 3c72-11e4-9a56-74d435052646TlsDxe/3aceb0c0-3c72-11e4-9a56- > > 74d435052646.ffs > > > 1134738 > > > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/23A089B3- > > EED5-4ac5-B2AB-43E3298C2343VariableSmm/23A089B3-EED5-4ac5-B2AB- > > 43E3298C2343.ffs > > > > Uh. So each driver which needs openssl has its own copy of the library? > > > > I wasn't aware of that, but yes, given we don't have dynamic linking > > this makes sense and also easily explains why we see such a big jump in > > size. > > > > > I am wondering, removing existing ciphers might impact other platforms. > > > Could you please suggest any less intrusive options without impacting > > > other platforms. > > > > I was thinking more about reviewing the chipers added. Pick the most > > commonly used ones instead of just adding them all for example. > > > > > I am new to EDK and what compile time options are you referring to? > Please > > > let me know if any other information is needed from the build. > > > > Compile time option would be a new "-D OPENSSL_ENABLE_ECC" switch. > > > > But I think Jiewen meant something else with "2 profiles": > > > > We could create two OpensslLib variants. One full-featured build with > > ecc enabled which TlsDxe could use (assuming better TLS support is your > > use case). And one less-featured variant for VariableSmm + > > SecureBootConfigDxe + SecurityStubDxe. > > > > That way we have the ecc code only once not four times in the firmware > > build. Possibly the less-featured could be stripped down even more when > > it doesn't need to support TLS any more. > > > > I'm also wondering why SecurityStubDxe needs OpensslLib ... > > > > take care & HTH, > > Gerd > > --000000000000d040b505d1147f6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Folks,=C2=A0

Sorry for the del= ay in my response. Thanks for the inputs. My bad for not understanding what= Jiewen was referring to,=C2=A0
I think he is suggesting to remove the = unused algorithms with in the ECC cipher. Not removing already available ci= phers.

Totally makes sense but it would involve mo= re testing against each private bios with the narrowed list of algorithms.<= /div>

+Harshit from Intel for context

Thanks,
Vineel


On Thu, Nov 11, 2021 at 5:26 AM Yao, Jiewen <jiewen.yao@intel.com> wrote:
Sorry, I don't= mean: one platform uses 2 different configuration.

That might be worse, because we lose the benefit on compression.
Ideally, no matter how many *same* copies you have, the compression algo wi= ll handle it and make only *one* copy. If you have two *different* copies, = then compression also may finally make *two* different copy.
I don't have data. I just feel it might be worse.

I mean two platform can choose 2 different configuration. But eventually, o= ne platform should select one of them consistently, such as using only one = CryptoDxe.inf.

In this case, you need carefully remove all unneeded algo.
For example, do you really need SM2 ?
Do you really need EdDSA ?
Do you really need ECX ?

Thank you
Yao Jiewen


> -----Original Message-----
> From: Gerd Hoffmann <kraxel@redhat.com>
> Sent: Thursday, November 11, 2021 9:06 PM
> To: Vineel Kovvuri <vineel.kovvuri@gmail.com>
> Cc: devel@ed= k2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> vineelko@m= icrosoft.com
> Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add el= liptic
> curve chipher algorithms
>
>=C2=A0 =C2=A0Hi,
>
> > The difference I see without ecc change and with the change is th= e increase
> > in file sizes for below ffs files,(other .ffs files remained unch= anged)
> >
> > Without ecc change:
> > 794742
> > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F80697E9-<= br> > 7FD6-4665-8646-88E33EF71DFCSecurityStubDxe/F80697E9-7FD6-4665-8646- > 88E33EF71DFC.ffs
> > 653470
> > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F0E6A44F-<= br> > 7195-41c3-AC64-54F202CD0A21SecureBootConfigDxe/F0E6A44F-7195-41c3-
> AC64-54F202CD0A21.ffs
> > 1174654
> >=C2=A0 /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/3ace= b0c0-
> 3c72-11e4-9a56-74d435052646TlsDxe/3aceb0c0-3c72-11e4-9a56-
> 74d435052646.ffs
> > 872594
> > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/23A089B3-<= br> > EED5-4ac5-B2AB-43E3298C2343VariableSmm/23A089B3-EED5-4ac5-B2AB-
> 43E3298C2343.ffs
> >
> > With ecc change:
> > 1058678
> >=C2=A0 /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F806= 97E9-
> 7FD6-4665-8646-88E33EF71DFCSecurityStubDxe/F80697E9-7FD6-4665-8646- > 88E33EF71DFC.ffs
> > 917214
> > /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/F0E6A44F-<= br> > 7195-41c3-AC64-54F202CD0A21SecureBootConfigDxe/F0E6A44F-7195-41c3-
> AC64-54F202CD0A21.ffs
> > 1470718
> >=C2=A0 /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/3ace= b0c0-
> 3c72-11e4-9a56-74d435052646TlsDxe/3aceb0c0-3c72-11e4-9a56-
> 74d435052646.ffs
> > 1134738
> >=C2=A0 /home/ubuntu/src/edk2/Build/Ovmf3264/NOOPT_GCC5/FV/Ffs/23A0= 89B3-
> EED5-4ac5-B2AB-43E3298C2343VariableSmm/23A089B3-EED5-4ac5-B2AB-
> 43E3298C2343.ffs
>
> Uh.=C2=A0 So each driver which needs openssl has its own copy of the l= ibrary?
>
> I wasn't aware of that, but yes, given we don't have dynamic l= inking
> this makes sense and also easily explains why we see such a big jump i= n
> size.
>
> > I am wondering, removing existing ciphers might impact other plat= forms.
> > Could you please suggest any less intrusive options without impac= ting
> > other platforms.
>
> I was thinking more about reviewing the chipers added.=C2=A0 Pick the = most
> commonly used ones instead of just adding them all for example.
>
> > I am new to EDK and what compile time options are you referring t= o? Please
> > let me know if any other information is needed from the build. >
> Compile time option would be a new "-D OPENSSL_ENABLE_ECC" s= witch.
>
> But I think Jiewen meant something else with "2 profiles": >
> We could create two OpensslLib variants.=C2=A0 One full-featured build= with
> ecc enabled which TlsDxe could use (assuming better TLS support is you= r
> use case).=C2=A0 And one less-featured variant for VariableSmm +
> SecureBootConfigDxe + SecurityStubDxe.
>
> That way we have the ecc code only once not four times in the firmware=
> build.=C2=A0 Possibly the less-featured could be stripped down even mo= re when
> it doesn't need to support TLS any more.
>
> I'm also wondering why SecurityStubDxe needs OpensslLib ...
>
> take care & HTH,
>=C2=A0 =C2=A0Gerd

--000000000000d040b505d1147f6a--