From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Pawel Polawski <ppolawsk@redhat.com>,
"Li, Yi1" <yi1.li@intel.com>,
Oliver Steffen <osteffen@redhat.com>,
"Wang, Jian J" <jian.j.wang@intel.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
"Jiang, Guomin" <guomin.jiang@intel.com>,
"Lu, Xiaoyu1" <xiaoyu1.lu@intel.com>,
"Justen, Jordan L" <jordan.l.justen@intel.com>
Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally.
Date: Mon, 9 May 2022 10:17:48 +0000 [thread overview]
Message-ID: <MW4PR11MB58724EBDA20EAA10F5B8F1CC8CC69@MW4PR11MB5872.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20220509094511.px6cl7jtjejr4y4x@sirius.home.kraxel.org>
Old == the launched platform, or the platform will be launched shortly where the flash size and layout are locked. It is huge risk to change the layout suddenly. And it is not practical to change the flash size. (E.g. How can you change your flash size on your laptop? )
New platform usually does not have such constrain, because it may include new feature and have more size, and the layout can be tuned later.
Talking about OPENSSL3.0.
First, I support the OPENSSL 3.0 enabling plan, because we should do that before OPENSSL 1.1 end of support.
You did a great job to enable OPENSSL3.0 in https://github.com/kraxel/edk2/tree/openssl3. I do appreciate that effort.
However, we also have size concern on OPENSSL3.0, according to the data you provided.
If we switch OPENSSL 1.1 to OPENSSL 3.0 immediately, then many platforms will be broken due to size issue. It is not practical.
I would recommend in this way:
1) Please keep the good work to enable OPENSSL3.0 in your personal branch.
2) If you have some way to control the size, then do it. If there is no much size difference by default, then you can submit to EDKII directly.
3) If there is significant size difference, we need figure out a way to resolve it. As temporary step, you may choose post OPENSSL3.0 to https://github.com/tianocore/edk2-staging, which is an official location for broader evaluation, collaboration and enhancement.
4) As enhancement, the basic idea is to make the library configurable. As such, if the old platform does not new functionality, it can still live with OPENSSL3.0.
The line is : same feature ==> same size (or minor reasonable increase), new feature ==> more size.
Thank you
Yao Jiewen
> -----Original Message-----
> From: Gerd Hoffmann <kraxel@redhat.com>
> Sent: Monday, May 9, 2022 5:45 PM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Pawel Polawski <ppolawsk@redhat.com>; Li, Yi1 <yi1.li@intel.com>; Oliver
> Steffen <osteffen@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Ard
> Biesheuvel <ardb+tianocore@kernel.org>; Jiang, Guomin
> <guomin.jiang@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>; Justen, Jordan
> L <jordan.l.justen@intel.com>
> Subject: Re: [edk2-devel] [PATCH 0/5] CryptoPkg/openssl: enable EC
> unconditionally.
>
> On Mon, May 09, 2022 at 01:38:35AM +0000, Yao, Jiewen wrote:
> > Thank you Gerd.
> >
> > I collected feedback from Intel BIOS team, both client and server, both old
> platform and new platform.
> >
> > In general, the new platform will leave enough space for crypto improvement.
> Size is not a big issue. The delta is acceptable.
> >
> > However, the old launched platforms only has limited flash space. This patch
> will break the current build because of size increase. Option (1) is not acceptable.
>
> Hmm. Does that mean the old platform (what is "old" here btw?) wouldn't
> be able to do the switch to openssl3 either?
>
> take care,
> Gerd
next prev parent reply other threads:[~2022-05-09 10:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 10:34 [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally Gerd Hoffmann
2022-05-02 10:34 ` [PATCH 1/5] Revert "CryptoPkg: Declare PcdEcEnabled in Library consuming OpensslLib" Gerd Hoffmann
2022-05-02 10:34 ` [PATCH 2/5] Revert "CryptoPkg: Make EC source file config-able" Gerd Hoffmann
2022-05-02 10:34 ` [PATCH 3/5] OvmfPkg: make DXEFV larger Gerd Hoffmann
2022-05-02 19:39 ` Ard Biesheuvel
2022-05-02 10:34 ` [PATCH 4/5] CryptoPkg/openssl: update generated files Gerd Hoffmann
2022-05-02 10:34 ` [PATCH 5/5] CryptoPkg/openssl: disable codestyle checks for " Gerd Hoffmann
2022-05-03 15:39 ` [PATCH 0/5] CryptoPkg/openssl: enable EC unconditionally Yao, Jiewen
2022-05-05 8:06 ` Gerd Hoffmann
2022-05-05 9:15 ` [edk2-devel] " Gerd Hoffmann
2022-05-09 1:38 ` Yao, Jiewen
2022-05-09 9:45 ` Gerd Hoffmann
2022-05-09 10:17 ` Yao, Jiewen [this message]
2022-05-09 11:27 ` Gerd Hoffmann
2022-05-09 11:47 ` James Bottomley
2022-05-09 12:03 ` Yao, Jiewen
2022-05-09 13:41 ` James Bottomley
2022-05-10 10:40 ` Gerd Hoffmann
2022-05-10 11:20 ` Yao, Jiewen
2022-05-10 14:31 ` James Bottomley
[not found] ` <16ED6E30C7B1AB9D.18911@groups.io>
2022-05-09 12:12 ` Yao, Jiewen
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=MW4PR11MB58724EBDA20EAA10F5B8F1CC8CC69@MW4PR11MB5872.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