public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org>, Gary Lin <glin@suse.com>,
	 Jiaxin Wu <jiaxin.wu@intel.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	 Qin Long <qin.long@intel.com>, Ruiyu Ni <ruiyu.ni@intel.com>,
	Ting Ye <ting.ye@intel.com>, Tomas Hoger <thoger@redhat.com>
Subject: Re: [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib
Date: Thu, 23 Feb 2017 22:25:26 +0000	[thread overview]
Message-ID: <CAKv+Gu8_a3G3=ax=WRqxc9RGCPc2W+ffcPDNf2M+E-0O8qAOWg@mail.gmail.com> (raw)
In-Reply-To: <20170223215744.7293-1-lersek@redhat.com>

On 23 February 2017 at 21:57, Laszlo Ersek <lersek@redhat.com> wrote:
> In commit 32387e0081db ("CryptoPkg: Enable ssl build in OpensslLib
> directly", 2016-12-14), we enabled libssl functionality in
> CryptoPkg/OpensslLib unconditionally.
>
> While that's real convenient, it is also overkill for platforms (or
> platform builds) that don't want TLS. The impact (beyond wasted build
> time) is that when the next vulnerability comes out that affects the
> libssl subset of OpenSSL, security teams all around will look at build
> logs and INF files, see the libssl files being built, and get nervous --
> without a good reason for such builds that don't actually *use* TLS.
>
> Let's make this easier on them (and thereby on ourselves!), and
> introduce an OpensslLibNoSsl instance, which excludes libssl.
>

I think it would be nicer to align with OpenSSL more closely, and
split the functionality into a libcrypto and a libssl library, and
include the latter only if TLS functionality is needed. However, I am
not volunteering to do the work, and this approach comes down to the
same thing, given that libssl depends on libcrypto, and so libcrypto
and libcrypto+libssl are the only combinations that make any sense.

> The edk2 integration script "process_files.sh" is updated to process
> both INF files in the same invocation.
>
> If noone disagrees with the concept, I'd appreciate if we could review &
> merge this series real fast. (Sorry about that, but a downstream
> deadline looms close, and I consider this sort of a blocker for the next
> rebase.)
>
> I updated the following platform packages:
> - ArmVirtPkg, because I know it never uses TLS (or HTTP boot for that
>   matter),
> - Nt32Pkg, because it exposes the TLS_ENABLE build flag,
> - OvmfPkg, because it exposes the TLS_ENABLE build flag.
>
> I didn't touch other packages because they don't expose TLS_ENABLE, and
> I don't have time to figure out if they want TLS built-in.
>
> I tested the new OpensslLibNoSsl instance with Secure Boot under OVMF.
>
> The series was formatted with "--find-copies-harder", which makes a real
> difference for patch #2.
>
> Tomas: if you would like to comment on this series, please subscribe to
> the edk2-devel list at
> <https://lists.01.org/mailman/listinfo/edk2-devel>, and also wait for
> your subscription request to complete, *before* responding.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Gary Lin <glin@suse.com>
> Cc: Jiaxin Wu <jiaxin.wu@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Qin Long <qin.long@intel.com>
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> Cc: Ting Ye <ting.ye@intel.com>
> Cc: Tomas Hoger <thoger@redhat.com>
>
> Thanks!
> Laszlo
>
> Laszlo Ersek (5):
>   CryptoPkg/OpensslLib: refresh OpensslLib.inf, opensslconf.h after
>     32387e00
>   CryptoPkg/OpensslLib: introduce OpensslLibNoSsl instance
>   ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl
>   Nt32Pkg: exclude libssl functionality from OpensslLib if
>     TLS_ENABLE=FALSE
>   OvmfPkg: exclude libssl functionality from OpensslLib if
>     TLS_ENABLE=FALSE
>
>  ArmVirtPkg/ArmVirt.dsc.inc                                           |  2 +-
>  Nt32Pkg/Nt32Pkg.dsc                                                  |  4 ++
>  OvmfPkg/OvmfPkgIa32.dsc                                              |  4 ++
>  OvmfPkg/OvmfPkgIa32X64.dsc                                           |  4 ++
>  OvmfPkg/OvmfPkgX64.dsc                                               |  4 ++
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf                          |  1 +
>  CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} | 55 ++------------------
>  CryptoPkg/Library/OpensslLib/opensslconf.h                           |  6 ---
>  CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} |  8 +--
>  CryptoPkg/Library/OpensslLib/process_files.sh                        | 27 +++++++---
>  10 files changed, 46 insertions(+), 69 deletions(-)
>  copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibNoSsl.inf} (90%)
>  copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibNoSsl.uni} (71%)
>
> --
> 2.9.3
>


  parent reply	other threads:[~2017-02-23 22:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23 21:57 [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib Laszlo Ersek
2017-02-23 21:57 ` [PATCH 1/5] CryptoPkg/OpensslLib: refresh OpensslLib.inf, opensslconf.h after 32387e00 Laszlo Ersek
2017-02-23 21:57 ` [PATCH 2/5] CryptoPkg/OpensslLib: introduce OpensslLibNoSsl instance Laszlo Ersek
2017-02-23 21:57 ` [PATCH 3/5] ArmVirtPkg: resolve OpensslLib to OpensslLibNoSsl Laszlo Ersek
2017-02-23 22:26   ` Ard Biesheuvel
2017-02-23 21:57 ` [PATCH 4/5] Nt32Pkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE Laszlo Ersek
2017-02-24  4:09   ` Ni, Ruiyu
     [not found]     ` <895558F6EA4E3B41AC93A00D163B72741629D991@SHSMSX103.ccr.corp.intel.com>
2017-02-24  9:46       ` Laszlo Ersek
2017-02-23 21:57 ` [PATCH 5/5] OvmfPkg: " Laszlo Ersek
2017-02-24  6:15   ` Gary Lin
2017-02-23 22:09 ` [URGENT-ish PATCH 0/5] ArmVirt- Nt32- Ovmf- CryptoPkg: conditionalize libssl presence in OpensslLib Laszlo Ersek
2017-02-23 22:25 ` Ard Biesheuvel [this message]
2017-02-24  3:32   ` Long, Qin

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='CAKv+Gu8_a3G3=ax=WRqxc9RGCPc2W+ffcPDNf2M+E-0O8qAOWg@mail.gmail.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