Repo:   https://github.com/lersek/edk2.git
Branch: https_cacert_rhbz_1536624

The trusted CA certificates for HTTPS boot can be specified in
EFI_TLS_CA_CERTIFICATE_VARIABLE. The platform may choose to create this
variable as volatile and set it on every boot as appropriate. The OVMF
feature is that the virtualization host passes down an fw_cfg blob that
carries the CA certs trusted on the host side, and the OVMF HTTPS boot
will verify web servers against that certificate bundle. (For (part of)
the host side implementation, refer to
<https://github.com/p11-glue/p11-kit/pull/137.)

The challenge for edk2 is that the CA cert list from the host side is
huge; on my laptop it is 182KB when formatted to the EFI_SIGNATURE_LIST
sequence expected by NetworkPkg/HttpDxe. Storing this in a non-volatile
EFI_TLS_CA_CERTIFICATE_VARIABLE is out of the question, but even when
making EFI_TLS_CA_CERTIFICATE_VARIABLE volatile, there are two limits
that need raising:

(1) the individual limit on volatile variables,
(2) the cumulative limit on volatile variables.

Regarding (1), the edk2 variable driver does not distinguish a limit for
volatile non-auth vs. non-volatile non-auth variables. The first patch
introduces "PcdMaxVolatileVariableSize" for this, in a backwards
compatible way (i.e. platforms that don't care need not learn about it).
The new PCD lets a platform raise the individual limit just for volatile
non-auth variables.

Regarding (2), OvmfPkg/EmuVariableFvbRuntimeDxe has a bug where it
abuses the cumulative limit on volatile variables for the live size of
the emulated non-volatile variable store. The difference is that
"volatile variables" are volatile on the UEFI service API level
(gRT->SetVariable() etc), and the driver stack expects the FVB impls to
use the non-volatile storage PCDs (regardless of the actual FVB backing
store). Patch #2 fixes this (without change in behavior) in
OvmfPkg/EmuVariableFvbRuntimeDxe.

Patch #3 adds a bit of documentation to the OVMF DSC files, as a
continuation of patch #2.

Patch #4 implements the feature, raising both limits (liberated in
earlier patches) and populating EFI_TLS_CA_CERTIFICATE_VARIABLE from
fw_cfg.

I've done reasonable HTTPS boot testing and regression testing too
(including "-bios" with OVMF and pflash with ArmVirtQemu). Indepdent
testing would be highly appreciated (feature and regression alike).

This email is too long and so are the commit messages, but I'm too tired
to trim them; apologies.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>

Thanks,
Laszlo

Laszlo Ersek (4):
  MdeModulePkg/Variable/RuntimeDxe: introduce PcdMaxVolatileVariableSize
  OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSize
  OvmfPkg: annotate "PcdVariableStoreSize :=
    PcdFlashNvStorageVariableSize"
  OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot

 MdeModulePkg/MdeModulePkg.dec                                     |   8 ++
 MdeModulePkg/MdeModulePkg.uni                                     |   8 ++
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c             |  50 ++++++--
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h             |  12 ++
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf |   1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c          |   2 +-
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf        |   1 +
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c                            |   6 +-
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf                          |   3 +-
 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c               | 133 ++++++++++++++++++++
 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf             |  55 ++++++++
 OvmfPkg/OvmfPkgIa32.dsc                                           |  15 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc                                        |  15 ++-
 OvmfPkg/OvmfPkgX64.dsc                                            |  15 ++-
 14 files changed, 308 insertions(+), 16 deletions(-)
 create mode 100644 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c
 create mode 100644 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf

-- 
2.14.1.3.gb7cf6e02401b

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On 03/28/18 22:26, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: https_cacert_rhbz_1536624

According to Star's feedback, I modified patch #1 as follows:

> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 5a9051648004..6caf603b3d30 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3842,10 +3842,6 @@ InitNonVolatileVariableStore (
>
>    mVariableModuleGlobal->MaxVariableSize = PcdGet32 (PcdMaxVariableSize);
>    mVariableModuleGlobal->MaxAuthVariableSize = ((PcdGet32 (PcdMaxAuthVariableSize) != 0) ? PcdGet32 (PcdMaxAuthVariableSize) : mVariableModuleGlobal->MaxVariableSize);
> -  mVariableModuleGlobal->MaxVolatileVariableSize = ((PcdGet32 (PcdMaxVolatileVariableSize) != 0) ?
> -                                                    PcdGet32 (PcdMaxVolatileVariableSize) :
> -                                                    mVariableModuleGlobal->MaxVariableSize
> -                                                    );
>
>    //
>    // Parse non-volatile variable data and get last variable offset.
> @@ -4261,6 +4257,10 @@ VariableCommonInitialize (
>      }
>    }
>
> +  mVariableModuleGlobal->MaxVolatileVariableSize = ((PcdGet32 (PcdMaxVolatileVariableSize) != 0) ?
> +                                                    PcdGet32 (PcdMaxVolatileVariableSize) :
> +                                                    mVariableModuleGlobal->MaxVariableSize
> +                                                    );
>    //
>    // Allocate memory for volatile variable store, note that there is a scratch space to store scratch data.
>    //

and I added the feedback tags like this:

> Reviewed-by: Gary Lin <glin@suse.com>
> Tested-by: Gary Lin <glin@suse.com>
> [lersek@redhat.com: set MaxVolatileVariableSize where Star suggested]
> Reviewed-by: Star Zeng <star.zeng@intel.com>

To the rest of the patches, I applied the feedback tags as usual.

Before pushing the set, I retested it with an OVMF HTTPS boot, and I
regression-retested it with an ArmVirtQemu disk boot.

Pushed as commit range 3d7ebd643431..9c7d0d499296.

Thanks everyone!
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Laszlo,

	(First, are you are plugfest? Let's chat.)

	Second, what need do you see for having KB worth of CA at UEFI's disposal? If HTTPS feature is primarily for PXE booting OS's, then it is likely the IT administrator who setup the PXE server also has a single CA they want use for PXE.   By allowing any and every CA to be installed (instead of having the user pick only the immediately needed CAs), we inadvertently open HTTPS to state-backed/well-financed malicious actors who can pay for quality SSL signing services.   (The less CAs then the less that can go wrong).

	This is not to prevent your patches going in, but would like to ensure manufacturers / admins know how to properly use the CA list

	
Regards,

Thomas Palmer

"I have only made this letter longer because I have not had the time to make it shorter" - Blaise Pascal


-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Wednesday, March 28, 2018 3:27 PM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>; Eric Dong <eric.dong@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Jordan Justen <jordan.l.justen@intel.com>; Gary Ching-Pang Lin <glin@suse.com>; Anthony Perard <anthony.perard@citrix.com>; Star Zeng <star.zeng@intel.com>
Subject: [edk2] [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list for HTTPS boot

Repo:   https://github.com/lersek/edk2.git
Branch: https_cacert_rhbz_1536624

The trusted CA certificates for HTTPS boot can be specified in EFI_TLS_CA_CERTIFICATE_VARIABLE. The platform may choose to create this variable as volatile and set it on every boot as appropriate. The OVMF feature is that the virtualization host passes down an fw_cfg blob that carries the CA certs trusted on the host side, and the OVMF HTTPS boot will verify web servers against that certificate bundle. (For (part of) the host side implementation, refer to
<https://github.com/p11-glue/p11-kit/pull/137.)

The challenge for edk2 is that the CA cert list from the host side is huge; on my laptop it is 182KB when formatted to the EFI_SIGNATURE_LIST sequence expected by NetworkPkg/HttpDxe. Storing this in a non-volatile EFI_TLS_CA_CERTIFICATE_VARIABLE is out of the question, but even when making EFI_TLS_CA_CERTIFICATE_VARIABLE volatile, there are two limits that need raising:

(1) the individual limit on volatile variables,
(2) the cumulative limit on volatile variables.

Regarding (1), the edk2 variable driver does not distinguish a limit for volatile non-auth vs. non-volatile non-auth variables. The first patch introduces "PcdMaxVolatileVariableSize" for this, in a backwards compatible way (i.e. platforms that don't care need not learn about it).
The new PCD lets a platform raise the individual limit just for volatile non-auth variables.

Regarding (2), OvmfPkg/EmuVariableFvbRuntimeDxe has a bug where it abuses the cumulative limit on volatile variables for the live size of the emulated non-volatile variable store. The difference is that "volatile variables" are volatile on the UEFI service API level
(gRT->SetVariable() etc), and the driver stack expects the FVB impls to use the non-volatile storage PCDs (regardless of the actual FVB backing store). Patch #2 fixes this (without change in behavior) in OvmfPkg/EmuVariableFvbRuntimeDxe.

Patch #3 adds a bit of documentation to the OVMF DSC files, as a continuation of patch #2.

Patch #4 implements the feature, raising both limits (liberated in earlier patches) and populating EFI_TLS_CA_CERTIFICATE_VARIABLE from fw_cfg.

I've done reasonable HTTPS boot testing and regression testing too (including "-bios" with OVMF and pflash with ArmVirtQemu). Indepdent testing would be highly appreciated (feature and regression alike).

This email is too long and so are the commit messages, but I'm too tired to trim them; apologies.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>

Thanks,
Laszlo

Laszlo Ersek (4):
  MdeModulePkg/Variable/RuntimeDxe: introduce PcdMaxVolatileVariableSize
  OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSize
  OvmfPkg: annotate "PcdVariableStoreSize :=
    PcdFlashNvStorageVariableSize"
  OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot

 MdeModulePkg/MdeModulePkg.dec                                     |   8 ++
 MdeModulePkg/MdeModulePkg.uni                                     |   8 ++
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c             |  50 ++++++--
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h             |  12 ++
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf |   1 +
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c          |   2 +-
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf        |   1 +
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c                            |   6 +-
 OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf                          |   3 +-
 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c               | 133 ++++++++++++++++++++
 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf             |  55 ++++++++
 OvmfPkg/OvmfPkgIa32.dsc                                           |  15 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc                                        |  15 ++-
 OvmfPkg/OvmfPkgX64.dsc                                            |  15 ++-
 14 files changed, 308 insertions(+), 16 deletions(-)  create mode 100644 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c
 create mode 100644 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf

--
2.14.1.3.gb7cf6e02401b

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On 03/29/18 06:56, Palmer, Thomas wrote:
> Laszlo,
>
>       (First, are you are plugfest? Let's chat.)

I like chatting :) but I'm not at the plugfest. I travel only once per
year, and that's to the KVM Forum.

>       Second, what need do you see for having KB worth of CA at UEFI's
>       disposal? If HTTPS feature is primarily for PXE booting OS's,
>       then it is likely the IT administrator who setup the PXE server
>       also has a single CA they want use for PXE.   By allowing any
>       and every CA to be installed (instead of having the user pick
>       only the immediately needed CAs), we inadvertently open HTTPS to
>       state-backed/well-financed malicious actors who can pay for
>       quality SSL signing services.   (The less CAs then the less that
>       can go wrong).

In a virt setup, we have to split this question in two.

(1) Why do we want to configure the guest from the host side?

(2) Why do we want to push down so many CA certs to the guest?

The answer to (1) is quite obvious: configuring the guest from the host
side allows for better automation, larger scale deployment, integration
with management tools etc.

Regarding (2), the premise is that the virtualization host administrator
has a carefully curated set of trusted CA certificates. It does not
necessarily need to be the full CA bundle from Mozilla, it just may be.
The feature that folks from our crypto and virt management tools teams
are requesting is that the HTTPS configuration in the guest, for OVMF
netbooting, not require *separate* administration from the host CA
curation.

(The same applies to the trusted cipher suites as well, and I'm going to
post patches for that too.)

>       This is not to prevent your patches going in, but would like to
>       ensure manufacturers / admins know how to properly use the CA
>       list

Oh, definitely. The idea here is *absolutely not* to encourage platform
vendors (physical or virtual) to heap shady CAs into
EFI_TLS_CA_CERTIFICATE_VARIABLE. This work is all about mechanism, not
policy; I'm just building the conduit through wich the virt host admin
can send down the CA list that they have *carefully* vetted for
host-side use already. If that list contains just one certificate, so be
it.

In my testing, the 182KB number comes from the default CA bundle from
Mozilla (the "ca-certificates" package) on my RHEL-7 laptop, which -- as
you can likely tell :) -- I haven't personally filtered down.

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Sorry to miss you this time, maybe next.

Yes, I was fine the fixes but wanted to know "why". Thanks


Regards,

Thomas Palmer

“I have only made this letter longer because I have not had the time to make it shorter” - Blaise Pascal

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com] 
Sent: Thursday, March 29, 2018 6:57 AM
To: Palmer, Thomas <thomas.palmer@hpe.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>; Eric Dong <eric.dong@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Jordan Justen <jordan.l.justen@intel.com>; Lin, Gary <GLin@suse.com>; Anthony Perard <anthony.perard@citrix.com>; Star Zeng <star.zeng@intel.com>
Subject: Re: [edk2] [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list for HTTPS boot

On 03/29/18 06:56, Palmer, Thomas wrote:
> Laszlo,
>
>       (First, are you are plugfest? Let's chat.)

I like chatting :) but I'm not at the plugfest. I travel only once per year, and that's to the KVM Forum.

>       Second, what need do you see for having KB worth of CA at UEFI's
>       disposal? If HTTPS feature is primarily for PXE booting OS's,
>       then it is likely the IT administrator who setup the PXE server
>       also has a single CA they want use for PXE.   By allowing any
>       and every CA to be installed (instead of having the user pick
>       only the immediately needed CAs), we inadvertently open HTTPS to
>       state-backed/well-financed malicious actors who can pay for
>       quality SSL signing services.   (The less CAs then the less that
>       can go wrong).

In a virt setup, we have to split this question in two.

(1) Why do we want to configure the guest from the host side?

(2) Why do we want to push down so many CA certs to the guest?

The answer to (1) is quite obvious: configuring the guest from the host side allows for better automation, larger scale deployment, integration with management tools etc.

Regarding (2), the premise is that the virtualization host administrator has a carefully curated set of trusted CA certificates. It does not necessarily need to be the full CA bundle from Mozilla, it just may be.
The feature that folks from our crypto and virt management tools teams are requesting is that the HTTPS configuration in the guest, for OVMF netbooting, not require *separate* administration from the host CA curation.

(The same applies to the trusted cipher suites as well, and I'm going to post patches for that too.)

>       This is not to prevent your patches going in, but would like to
>       ensure manufacturers / admins know how to properly use the CA
>       list

Oh, definitely. The idea here is *absolutely not* to encourage platform vendors (physical or virtual) to heap shady CAs into EFI_TLS_CA_CERTIFICATE_VARIABLE. This work is all about mechanism, not policy; I'm just building the conduit through wich the virt host admin can send down the CA list that they have *carefully* vetted for host-side use already. If that list contains just one certificate, so be it.

In my testing, the 182KB number comes from the default CA bundle from Mozilla (the "ca-certificates" package) on my RHEL-7 laptop, which -- as you can likely tell :) -- I haven't personally filtered down.

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On Wed, Mar 28, 2018 at 10:26:47PM +0200, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: https_cacert_rhbz_1536624
> 
This patch series is great and I like it :)
Configuring the CA list dynamically is really useful and flexible for
the administrator.

I read the code and tested it with my self-signed server, and it worked
as expected.

Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>

> The trusted CA certificates for HTTPS boot can be specified in
> EFI_TLS_CA_CERTIFICATE_VARIABLE. The platform may choose to create this
> variable as volatile and set it on every boot as appropriate. The OVMF
> feature is that the virtualization host passes down an fw_cfg blob that
> carries the CA certs trusted on the host side, and the OVMF HTTPS boot
> will verify web servers against that certificate bundle. (For (part of)
> the host side implementation, refer to
> <https://github.com/p11-glue/p11-kit/pull/137.)
> 
> The challenge for edk2 is that the CA cert list from the host side is
> huge; on my laptop it is 182KB when formatted to the EFI_SIGNATURE_LIST
> sequence expected by NetworkPkg/HttpDxe. Storing this in a non-volatile
> EFI_TLS_CA_CERTIFICATE_VARIABLE is out of the question, but even when
> making EFI_TLS_CA_CERTIFICATE_VARIABLE volatile, there are two limits
> that need raising:
> 
> (1) the individual limit on volatile variables,
> (2) the cumulative limit on volatile variables.
> 
> Regarding (1), the edk2 variable driver does not distinguish a limit for
> volatile non-auth vs. non-volatile non-auth variables. The first patch
> introduces "PcdMaxVolatileVariableSize" for this, in a backwards
> compatible way (i.e. platforms that don't care need not learn about it).
> The new PCD lets a platform raise the individual limit just for volatile
> non-auth variables.
> 
> Regarding (2), OvmfPkg/EmuVariableFvbRuntimeDxe has a bug where it
> abuses the cumulative limit on volatile variables for the live size of
> the emulated non-volatile variable store. The difference is that
> "volatile variables" are volatile on the UEFI service API level
> (gRT->SetVariable() etc), and the driver stack expects the FVB impls to
> use the non-volatile storage PCDs (regardless of the actual FVB backing
> store). Patch #2 fixes this (without change in behavior) in
> OvmfPkg/EmuVariableFvbRuntimeDxe.
> 
> Patch #3 adds a bit of documentation to the OVMF DSC files, as a
> continuation of patch #2.
> 
> Patch #4 implements the feature, raising both limits (liberated in
> earlier patches) and populating EFI_TLS_CA_CERTIFICATE_VARIABLE from
> fw_cfg.
> 
> I've done reasonable HTTPS boot testing and regression testing too
> (including "-bios" with OVMF and pflash with ArmVirtQemu). Indepdent
> testing would be highly appreciated (feature and regression alike).
> 
> This email is too long and so are the commit messages, but I'm too tired
> to trim them; apologies.
> 
> Cc: Anthony Perard <anthony.perard@citrix.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Gary Ching-Pang Lin <glin@suse.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Julien Grall <julien.grall@linaro.org>
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> Cc: Star Zeng <star.zeng@intel.com>
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (4):
>   MdeModulePkg/Variable/RuntimeDxe: introduce PcdMaxVolatileVariableSize
>   OvmfPkg/EmuVariableFvbRuntimeDxe: stop using PcdVariableStoreSize
>   OvmfPkg: annotate "PcdVariableStoreSize :=
>     PcdFlashNvStorageVariableSize"
>   OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot
> 
>  MdeModulePkg/MdeModulePkg.dec                                     |   8 ++
>  MdeModulePkg/MdeModulePkg.uni                                     |   8 ++
>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c             |  50 ++++++--
>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h             |  12 ++
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf |   1 +
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c          |   2 +-
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf        |   1 +
>  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c                            |   6 +-
>  OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf                          |   3 +-
>  OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c               | 133 ++++++++++++++++++++
>  OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf             |  55 ++++++++
>  OvmfPkg/OvmfPkgIa32.dsc                                           |  15 ++-
>  OvmfPkg/OvmfPkgIa32X64.dsc                                        |  15 ++-
>  OvmfPkg/OvmfPkgX64.dsc                                            |  15 ++-
>  14 files changed, 308 insertions(+), 16 deletions(-)
>  create mode 100644 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c
>  create mode 100644 OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
> 
> -- 
> 2.14.1.3.gb7cf6e02401b
> 
> 
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel