public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
	Vineel Kovvuri <vineel.kovvuri@gmail.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"vineelko@microsoft.com" <vineelko@microsoft.com>
Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms
Date: Thu, 11 Nov 2021 13:26:49 +0000	[thread overview]
Message-ID: <PH0PR11MB4885F2955C20D0121280D39A8C949@PH0PR11MB4885.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20211111130552.qo5a33ki7ikipqpf@sirius.home.kraxel.org>

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 <kraxel@redhat.com>
> Sent: Thursday, November 11, 2021 9:06 PM
> To: Vineel Kovvuri <vineel.kovvuri@gmail.com>
> Cc: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> 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


  reply	other threads:[~2021-11-11 13:26 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-12  5:38 [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms Vineel Kovvuri
2021-10-12  5:38 ` [PATCH 2/2] Allow wildcards in hostname Vineel Kovvuri
2021-10-13  2:50   ` Yao, Jiewen
2021-10-13  2:45 ` [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms Yao, Jiewen
2021-10-17  2:49 ` Yao, Jiewen
2021-10-18 20:06   ` vineelko
2021-11-03  0:37     ` Yao, Jiewen
2021-11-03  8:34       ` Vineel Kovvuri
2021-11-08 22:29         ` [edk2-devel] " Vineel Kovvuri
2021-11-09  8:06           ` Yao, Jiewen
2021-11-09  8:58             ` Gerd Hoffmann
2021-11-10 16:18               ` Vineel Kovvuri
2021-11-11 13:05                 ` Gerd Hoffmann
2021-11-11 13:26                   ` Yao, Jiewen [this message]
2021-11-18 18:40                     ` Vineel Kovvuri
2022-02-23  2:32                       ` yi1 li
2022-02-23  2:46                         ` Vineel Kovvuri
2022-02-23  2:54                           ` yi1 li
2022-02-24  6:51                             ` Vineel Kovvuri
2022-02-24  8:20                               ` yi1 li
2022-02-25 17:51                                 ` Vineel Kovvuri
2022-02-26 15:54                                   ` yi1 li
2022-02-28  8:24                                   ` yi1 li
2022-03-01 14:04                                     ` Gerd Hoffmann
2022-03-01 17:38                                       ` Sean
2022-03-02  4:23                                       ` yi1 li
2022-03-02  6:59                                         ` Yao, Jiewen
2022-03-02  7:42                                           ` Gerd Hoffmann
2022-03-02 11:56                                             ` Yao, Jiewen
2022-03-03  8:43                                               ` yi1 li
2022-03-03 10:05                                                 ` Yao, Jiewen
2022-03-04  2:15                                                   ` Vineel Kovvuri
2022-03-02  7:58                                         ` Gerd Hoffmann
2022-03-03  6:30                                   ` Vineel Kovvuri
2022-03-03  6:37                                     ` Vineel Kovvuri
2021-11-09  8:55           ` Gerd Hoffmann

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=PH0PR11MB4885F2955C20D0121280D39A8C949@PH0PR11MB4885.namprd11.prod.outlook.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