Re: internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE

["Zeng, Star" <star.zeng@intel.com>]

Is there a PCD pointers to the siglist?


For adding PcdMaxVolatileVariableSize: non-authenticated, volatile, I think it is acceptable if there are use cases.


Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Wednesday, March 28, 2018 10:32 AM
To: Fu, Siyuan <siyuan.fu@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>; Daniel P. Berrange <berrange@redhat.com>; Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE

Hi,

On 03/21/18 02:30, Fu, Siyuan wrote:
> Hi, Laszlo
>
> The data structure of EFI_TLS_CA_CERTIFICATE_VARIABLE is 
> EFI_SIGNATURE_LIST and we have documented this in HTTPs Boot wiki
> page:
> https://github.com/tianocore/tianocore.github.io/wiki/HTTPS-Boot
>
> You can refer section 31.4.1 "Signature Database" in UEFI 2.7 A for a 
> detail description of EFI_SIGNATURE_LIST structure.

I implemented a "p11-kit" extractor so that it produces a sequence of EFI_SIGNATURE_LIST objects, each siglist containing a single EFI_SIGNATURE_DATA object (with an X509 CA certificate in it).

In order to test that, I started writing the OVMF enablement patches, on top of the following series (pending review):

  [edk2] [PATCH 0/5] NetworkPkg: HTTP and TLS updates

In the OVMF platform code, I created EFI_TLS_CA_CERTIFICATE_VARIABLE as a *volatile* and boot-service only variable, so that there would be no flash impact, regardless of the number and size of the certificates that the extractor produced.

Unfortunately, I still ran into a limitation here. The EFI_SIGNATURE_LIST bundle produced by the extractor is 182 KB in size (it comes from the Mozilla CA root certificate bundle, aka the "ca-certificates" package). In order to create such a large variable, I had to raise the following two PCDs for OVMF:

- PcdVariableStoreSize: this controls the cumulative storage size for
  *volatile* variables.

- PcdMaxVariableSize: this limits the individual variable size for
  non-authenticated variables, *regardless* of their volatility.

I set PcdMaxVariableSize to 256KB (to accommodate the 182KB size mentioned above, and to leave a bit of margin). I set PcdVariableStoreSize to 512KB (so that there would be quite a bit of volatile space left after a 256KB volatile variable was created).

And this is where the variable driver runs into an assertion failure:

> ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3809):
> GetNonVolatileMaxVariableSize () < (VariableStoreLength - sizeof
> (VARIABLE_STORE_HEADER))

The GetNonVolatileMaxVariableSize() function calculates the maximum of PcdMaxVariableSize and PcdMaxAuthVariableSize. This is not good because I didn't mean to raise PcdMaxVariableSize for non-volatile purposes; I only meant to raise it for volatile storage.

Then the InitNonVolatileVariableStore() function attempts to fit this maximum into the *flash* storage. Obviously, individual 256KB variables (which I never meant to place into flash) don't fit into flash, and the
ASSERT() fires.

The issue is that the variable driver does not distinguish the max variable size between volatile and non-volatile storage, and the non-volatile availability effectively limits the volatile one.

I think we should have three PCDs:

- PcdMaxVariableSize: non-authenticated, non-volatile
- PcdMaxAuthVariableSize: authenticated, non-volatile
- PcdMaxVolatileVariableSize: non-authenticated, volatile

(The fourth variation needs no PCD because authenticated volatile variables make no sense.)

How can we solve this?

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