[PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Laszlo Ersek]

In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
facility for exposing the host-side TLS cipher suite configuration to
OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
HTTPS boot. This complements the forwarding of the host-side crypto policy
from the host to the guest -- the other facet was the set of CA
certificates (for which p11-kit patches had been upstreamed, on the host
side).

Mention the new command line options in "OvmfPkg/README".

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 OvmfPkg/README | 24 ++++++++++++--------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/README b/OvmfPkg/README
index 3dd28474ead4..2009d9d29796 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -294,67 +294,73 @@ and encrypted connection.
 
   You can also append a certificate to the existing list with the following
   command:
 
   efisiglist -i <old certdb> -a <cert file> -o <new certdb>
 
   NOTE: You may need the patch to make efisiglist generate the correct header.
   (https://github.com/rhboot/pesign/pull/40)
 
 * Besides the trusted certificates, it's also possible to configure the trusted
   cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
 
-  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
-
   OVMF expects a binary UINT16 array which comprises the cipher suites HEX
   IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
   suite from the intersection of the given list and the built-in cipher
   suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
   built-in ones.
 
-  While the tool(*5) to create the cipher suite array is still under
-  development, the array can be generated with the following script:
+  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
+  cipher suites from the host side to OVMF:
+
+  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
+  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
+
+  (Refer to the QEMU manual and to
+  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
+  information on the "priority" property.)
+
+  Using QEMU 5.0 or earlier, the array has to be passed from a file:
+
+  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
+
+  whose contents can be generated with the following script, for example:
 
   export LC_ALL=C
   openssl ciphers -V \
   | sed -r -n \
      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
   | xargs -r -- printf -- '%b' > ciphers.bin
 
   This script creates ciphers.bin that contains all the cipher suite IDs
   supported by openssl according to the local host configuration.
 
   You may want to enable only a limited set of cipher suites. Then, you
   should check the validity of your list first:
 
   openssl ciphers -V <cipher list>
 
   If all the cipher suites in your list map to the proper HEX IDs, go ahead
   to modify the script and execute it:
 
   export LC_ALL=C
   openssl ciphers -V <cipher list> \
   | sed -r -n \
      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
   | xargs -r -- printf -- '%b' > ciphers.bin
 
-* In the future (after release 2.12), QEMU should populate both above fw_cfg
-  files automatically from the local host configuration, and enable the user
-  to override either with dedicated options or properties.
-
 (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
 (*2) p11-kit: https://github.com/p11-glue/p11-kit/
 (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
 (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
-(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
 
 === OVMF Flash Layout ===
 
 Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
 appears in QEMU's physical address space just below 4GB (0x100000000).
 
 OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
 FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
 1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
 image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
 
 Using the 1MB or 2MB image, the layout of the firmware device in memory looks
-- 
2.19.1.3.g30247aa5d201

Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Gary Lin]

On Mon, Sep 07, 2020 at 06:18:25PM +0200, Laszlo Ersek wrote:
> In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
> facility for exposing the host-side TLS cipher suite configuration to
> OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
> HTTPS boot. This complements the forwarding of the host-side crypto policy
> from the host to the guest -- the other facet was the set of CA
> certificates (for which p11-kit patches had been upstreamed, on the host
> side).
> 
> Mention the new command line options in "OvmfPkg/README".

Looks good to me :)

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

> 
> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
> Cc: Gary Lin <glin@suse.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>  OvmfPkg/README | 24 ++++++++++++--------
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 3dd28474ead4..2009d9d29796 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -294,67 +294,73 @@ and encrypted connection.
>  
>    You can also append a certificate to the existing list with the following
>    command:
>  
>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>  
>    NOTE: You may need the patch to make efisiglist generate the correct header.
>    (https://github.com/rhboot/pesign/pull/40)
>  
>  * Besides the trusted certificates, it's also possible to configure the trusted
>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>  
> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
> -
>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>    suite from the intersection of the given list and the built-in cipher
>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>    built-in ones.
>  
> -  While the tool(*5) to create the cipher suite array is still under
> -  development, the array can be generated with the following script:
> +  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
> +  cipher suites from the host side to OVMF:
> +
> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
> +
> +  (Refer to the QEMU manual and to
> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
> +  information on the "priority" property.)
> +
> +  Using QEMU 5.0 or earlier, the array has to be passed from a file:
> +
> +  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
> +
> +  whose contents can be generated with the following script, for example:
>  
>    export LC_ALL=C
>    openssl ciphers -V \
>    | sed -r -n \
>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>    | xargs -r -- printf -- '%b' > ciphers.bin
>  
>    This script creates ciphers.bin that contains all the cipher suite IDs
>    supported by openssl according to the local host configuration.
>  
>    You may want to enable only a limited set of cipher suites. Then, you
>    should check the validity of your list first:
>  
>    openssl ciphers -V <cipher list>
>  
>    If all the cipher suites in your list map to the proper HEX IDs, go ahead
>    to modify the script and execute it:
>  
>    export LC_ALL=C
>    openssl ciphers -V <cipher list> \
>    | sed -r -n \
>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>    | xargs -r -- printf -- '%b' > ciphers.bin
>  
> -* In the future (after release 2.12), QEMU should populate both above fw_cfg
> -  files automatically from the local host configuration, and enable the user
> -  to override either with dedicated options or properties.
> -
>  (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
>  (*2) p11-kit: https://github.com/p11-glue/p11-kit/
>  (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
>  (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
> -(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
>  
>  === OVMF Flash Layout ===
>  
>  Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
>  appears in QEMU's physical address space just below 4GB (0x100000000).
>  
>  OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
>  FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
>  1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
>  image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
>  
>  Using the 1MB or 2MB image, the layout of the firmware device in memory looks
> -- 
> 2.19.1.3.g30247aa5d201
> 

Re: [edk2-devel] [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Laszlo Ersek]

On 09/08/20 05:40, Gary Lin wrote:
> On Mon, Sep 07, 2020 at 06:18:25PM +0200, Laszlo Ersek wrote:
>> In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
>> facility for exposing the host-side TLS cipher suite configuration to
>> OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
>> HTTPS boot. This complements the forwarding of the host-side crypto policy
>> from the host to the guest -- the other facet was the set of CA
>> certificates (for which p11-kit patches had been upstreamed, on the host
>> side).
>>
>> Mention the new command line options in "OvmfPkg/README".
> 
> Looks good to me :)
> 
> Reviewed-by: Gary Lin <glin@suse.com>

Thanks!

I'll have to respin this, bumping the QEMU version numbers, and updating
the QEMU commit references in the commit message.

There's an issue in QEMU 5.1 that prevents "-fw_cfg name=...,gen_id=..."
from working. We'll have to fix that for 5.2 (and hopefully backport the
fix to 5.1 stable).

Laszlo

> 
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
>> Cc: Gary Lin <glin@suse.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>  OvmfPkg/README | 24 ++++++++++++--------
>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/OvmfPkg/README b/OvmfPkg/README
>> index 3dd28474ead4..2009d9d29796 100644
>> --- a/OvmfPkg/README
>> +++ b/OvmfPkg/README
>> @@ -294,67 +294,73 @@ and encrypted connection.
>>  
>>    You can also append a certificate to the existing list with the following
>>    command:
>>  
>>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>>  
>>    NOTE: You may need the patch to make efisiglist generate the correct header.
>>    (https://github.com/rhboot/pesign/pull/40)
>>  
>>  * Besides the trusted certificates, it's also possible to configure the trusted
>>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>>  
>> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>> -
>>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>>    suite from the intersection of the given list and the built-in cipher
>>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>>    built-in ones.
>>  
>> -  While the tool(*5) to create the cipher suite array is still under
>> -  development, the array can be generated with the following script:
>> +  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
>> +  cipher suites from the host side to OVMF:
>> +
>> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
>> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
>> +
>> +  (Refer to the QEMU manual and to
>> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
>> +  information on the "priority" property.)
>> +
>> +  Using QEMU 5.0 or earlier, the array has to be passed from a file:
>> +
>> +  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>> +
>> +  whose contents can be generated with the following script, for example:
>>  
>>    export LC_ALL=C
>>    openssl ciphers -V \
>>    | sed -r -n \
>>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>>    | xargs -r -- printf -- '%b' > ciphers.bin
>>  
>>    This script creates ciphers.bin that contains all the cipher suite IDs
>>    supported by openssl according to the local host configuration.
>>  
>>    You may want to enable only a limited set of cipher suites. Then, you
>>    should check the validity of your list first:
>>  
>>    openssl ciphers -V <cipher list>
>>  
>>    If all the cipher suites in your list map to the proper HEX IDs, go ahead
>>    to modify the script and execute it:
>>  
>>    export LC_ALL=C
>>    openssl ciphers -V <cipher list> \
>>    | sed -r -n \
>>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>>    | xargs -r -- printf -- '%b' > ciphers.bin
>>  
>> -* In the future (after release 2.12), QEMU should populate both above fw_cfg
>> -  files automatically from the local host configuration, and enable the user
>> -  to override either with dedicated options or properties.
>> -
>>  (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
>>  (*2) p11-kit: https://github.com/p11-glue/p11-kit/
>>  (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
>>  (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
>> -(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
>>  
>>  === OVMF Flash Layout ===
>>  
>>  Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
>>  appears in QEMU's physical address space just below 4GB (0x100000000).
>>  
>>  OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
>>  FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
>>  1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
>>  image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
>>  
>>  Using the 1MB or 2MB image, the layout of the firmware device in memory looks
>> -- 
>> 2.19.1.3.g30247aa5d201
>>
> 
> 
> 
> 

Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Philippe Mathieu-Daudé]

On 9/7/20 6:18 PM, Laszlo Ersek wrote:
> In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
> facility for exposing the host-side TLS cipher suite configuration to
> OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
> HTTPS boot. This complements the forwarding of the host-side crypto policy
> from the host to the guest -- the other facet was the set of CA
> certificates (for which p11-kit patches had been upstreamed, on the host
> side).
> 
> Mention the new command line options in "OvmfPkg/README".
> 
> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
> Cc: Gary Lin <glin@suse.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852

Thanks for addressing this BZ for me...

> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
>  OvmfPkg/README | 24 ++++++++++++--------
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 3dd28474ead4..2009d9d29796 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -294,67 +294,73 @@ and encrypted connection.
>  
>    You can also append a certificate to the existing list with the following
>    command:
>  
>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>  
>    NOTE: You may need the patch to make efisiglist generate the correct header.
>    (https://github.com/rhboot/pesign/pull/40)
>  
>  * Besides the trusted certificates, it's also possible to configure the trusted
>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>  
> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
> -
>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>    suite from the intersection of the given list and the built-in cipher
>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>    built-in ones.
>  
> -  While the tool(*5) to create the cipher suite array is still under
> -  development, the array can be generated with the following script:
> +  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
> +  cipher suites from the host side to OVMF:
> +
> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
> +
> +  (Refer to the QEMU manual and to
> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
> +  information on the "priority" property.)
> +
> +  Using QEMU 5.0 or earlier, the array has to be passed from a file:

What about using a '-' to list each "Using QEMU ..." and make the
separation clearer?

Regardless:
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>

> +
> +  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
> +
> +  whose contents can be generated with the following script, for example:
>  
>    export LC_ALL=C
>    openssl ciphers -V \
>    | sed -r -n \
>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>    | xargs -r -- printf -- '%b' > ciphers.bin
>  
>    This script creates ciphers.bin that contains all the cipher suite IDs
>    supported by openssl according to the local host configuration.
>  
>    You may want to enable only a limited set of cipher suites. Then, you
>    should check the validity of your list first:
>  
>    openssl ciphers -V <cipher list>
>  
>    If all the cipher suites in your list map to the proper HEX IDs, go ahead
>    to modify the script and execute it:
>  
>    export LC_ALL=C
>    openssl ciphers -V <cipher list> \
>    | sed -r -n \
>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>    | xargs -r -- printf -- '%b' > ciphers.bin
>  
> -* In the future (after release 2.12), QEMU should populate both above fw_cfg
> -  files automatically from the local host configuration, and enable the user
> -  to override either with dedicated options or properties.
> -
>  (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
>  (*2) p11-kit: https://github.com/p11-glue/p11-kit/
>  (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
>  (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
> -(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
>  
>  === OVMF Flash Layout ===
>  
>  Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
>  appears in QEMU's physical address space just below 4GB (0x100000000).
>  
>  OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
>  FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
>  1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
>  image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
>  
>  Using the 1MB or 2MB image, the layout of the firmware device in memory looks
> 

Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Laszlo Ersek]

On 09/09/20 18:21, Philippe Mathieu-Daudé wrote:
> On 9/7/20 6:18 PM, Laszlo Ersek wrote:
>> In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
>> facility for exposing the host-side TLS cipher suite configuration to
>> OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
>> HTTPS boot. This complements the forwarding of the host-side crypto policy
>> from the host to the guest -- the other facet was the set of CA
>> certificates (for which p11-kit patches had been upstreamed, on the host
>> side).
>>
>> Mention the new command line options in "OvmfPkg/README".
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
>> Cc: Gary Lin <glin@suse.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
> 
> Thanks for addressing this BZ for me...
> 
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>  OvmfPkg/README | 24 ++++++++++++--------
>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/OvmfPkg/README b/OvmfPkg/README
>> index 3dd28474ead4..2009d9d29796 100644
>> --- a/OvmfPkg/README
>> +++ b/OvmfPkg/README
>> @@ -294,67 +294,73 @@ and encrypted connection.
>>  
>>    You can also append a certificate to the existing list with the following
>>    command:
>>  
>>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>>  
>>    NOTE: You may need the patch to make efisiglist generate the correct header.
>>    (https://github.com/rhboot/pesign/pull/40)
>>  
>>  * Besides the trusted certificates, it's also possible to configure the trusted
>>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>>  
>> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>> -
>>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>>    suite from the intersection of the given list and the built-in cipher
>>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>>    built-in ones.
>>  
>> -  While the tool(*5) to create the cipher suite array is still under
>> -  development, the array can be generated with the following script:
>> +  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
>> +  cipher suites from the host side to OVMF:
>> +
>> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
>> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
>> +
>> +  (Refer to the QEMU manual and to
>> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
>> +  information on the "priority" property.)
>> +
>> +  Using QEMU 5.0 or earlier, the array has to be passed from a file:
> 
> What about using a '-' to list each "Using QEMU ..." and make the
> separation clearer?

I can do that, yes. There are three possibilities:

- prefix just one line (in each affected paragraph) with the hyphen,

- prefix the first line of each paragraph with the hyphen, plus indent
the rest of the *same paragraph* by 2 spaces.

- prefix the first line of each paragraph with the hyphen, plus indent
the rest of the *text* that applies to the QEMU versions being discussed.

Which one do you prefer?

Thanks,
Laszlo

> 
> Regardless:
> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>
> 
>> +
>> +  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>> +
>> +  whose contents can be generated with the following script, for example:
>>  
>>    export LC_ALL=C
>>    openssl ciphers -V \
>>    | sed -r -n \
>>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>>    | xargs -r -- printf -- '%b' > ciphers.bin
>>  
>>    This script creates ciphers.bin that contains all the cipher suite IDs
>>    supported by openssl according to the local host configuration.
>>  
>>    You may want to enable only a limited set of cipher suites. Then, you
>>    should check the validity of your list first:
>>  
>>    openssl ciphers -V <cipher list>
>>  
>>    If all the cipher suites in your list map to the proper HEX IDs, go ahead
>>    to modify the script and execute it:
>>  
>>    export LC_ALL=C
>>    openssl ciphers -V <cipher list> \
>>    | sed -r -n \
>>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>>    | xargs -r -- printf -- '%b' > ciphers.bin
>>  
>> -* In the future (after release 2.12), QEMU should populate both above fw_cfg
>> -  files automatically from the local host configuration, and enable the user
>> -  to override either with dedicated options or properties.
>> -
>>  (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
>>  (*2) p11-kit: https://github.com/p11-glue/p11-kit/
>>  (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
>>  (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
>> -(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
>>  
>>  === OVMF Flash Layout ===
>>  
>>  Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
>>  appears in QEMU's physical address space just below 4GB (0x100000000).
>>  
>>  OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
>>  FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
>>  1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
>>  image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
>>  
>>  Using the 1MB or 2MB image, the layout of the firmware device in memory looks
>>
> 

Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Philippe Mathieu-Daudé]

Hi Laszlo,

On 9/10/20 8:02 AM, Laszlo Ersek wrote:
> On 09/09/20 18:21, Philippe Mathieu-Daudé wrote:
>> On 9/7/20 6:18 PM, Laszlo Ersek wrote:
>>> In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
>>> facility for exposing the host-side TLS cipher suite configuration to
>>> OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
>>> HTTPS boot. This complements the forwarding of the host-side crypto policy
>>> from the host to the guest -- the other facet was the set of CA
>>> certificates (for which p11-kit patches had been upstreamed, on the host
>>> side).
>>>
>>> Mention the new command line options in "OvmfPkg/README".
>>>
>>> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
>>> Cc: Gary Lin <glin@suse.com>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
>>
>> Thanks for addressing this BZ for me...
>>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>> ---
>>>  OvmfPkg/README | 24 ++++++++++++--------
>>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/OvmfPkg/README b/OvmfPkg/README
>>> index 3dd28474ead4..2009d9d29796 100644
>>> --- a/OvmfPkg/README
>>> +++ b/OvmfPkg/README
>>> @@ -294,67 +294,73 @@ and encrypted connection.
>>>  
>>>    You can also append a certificate to the existing list with the following
>>>    command:
>>>  
>>>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>>>  
>>>    NOTE: You may need the patch to make efisiglist generate the correct header.
>>>    (https://github.com/rhboot/pesign/pull/40)
>>>  
>>>  * Besides the trusted certificates, it's also possible to configure the trusted
>>>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>>>  
>>> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>>> -
>>>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>>>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>>>    suite from the intersection of the given list and the built-in cipher
>>>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>>>    built-in ones.
>>>  
>>> -  While the tool(*5) to create the cipher suite array is still under
>>> -  development, the array can be generated with the following script:
>>> +  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
>>> +  cipher suites from the host side to OVMF:
>>> +
>>> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
>>> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
>>> +
>>> +  (Refer to the QEMU manual and to
>>> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
>>> +  information on the "priority" property.)
>>> +
>>> +  Using QEMU 5.0 or earlier, the array has to be passed from a file:
>>
>> What about using a '-' to list each "Using QEMU ..." and make the
>> separation clearer?
> 
> I can do that, yes. There are three possibilities:
> 
> - prefix just one line (in each affected paragraph) with the hyphen,
> 
> - prefix the first line of each paragraph with the hyphen, plus indent
> the rest of the *same paragraph* by 2 spaces.

I'd go with this possibility. Clear and easy.

> 
> - prefix the first line of each paragraph with the hyphen, plus indent
> the rest of the *text* that applies to the QEMU versions being discussed.

(Note that would be my *visual* preference, but I don't think it's
worth it, I prefer we keep the diff short and easy to review).

> 
> Which one do you prefer?
> 
> Thanks,
> Laszlo
> 
>>
>> Regardless:
>> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
>> Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>
>>
>>> +
>>> +  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>>> +
>>> +  whose contents can be generated with the following script, for example:
>>>  
>>>    export LC_ALL=C
>>>    openssl ciphers -V \
>>>    | sed -r -n \
>>>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>>>    | xargs -r -- printf -- '%b' > ciphers.bin
>>>  
>>>    This script creates ciphers.bin that contains all the cipher suite IDs
>>>    supported by openssl according to the local host configuration.
>>>  
>>>    You may want to enable only a limited set of cipher suites. Then, you
>>>    should check the validity of your list first:
>>>  
>>>    openssl ciphers -V <cipher list>
>>>  
>>>    If all the cipher suites in your list map to the proper HEX IDs, go ahead
>>>    to modify the script and execute it:
>>>  
>>>    export LC_ALL=C
>>>    openssl ciphers -V <cipher list> \
>>>    | sed -r -n \
>>>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>>>    | xargs -r -- printf -- '%b' > ciphers.bin
>>>  
>>> -* In the future (after release 2.12), QEMU should populate both above fw_cfg
>>> -  files automatically from the local host configuration, and enable the user
>>> -  to override either with dedicated options or properties.
>>> -
>>>  (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
>>>  (*2) p11-kit: https://github.com/p11-glue/p11-kit/
>>>  (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
>>>  (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
>>> -(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
>>>  
>>>  === OVMF Flash Layout ===
>>>  
>>>  Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
>>>  appears in QEMU's physical address space just below 4GB (0x100000000).
>>>  
>>>  OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
>>>  FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
>>>  1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
>>>  image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
>>>  
>>>  Using the 1MB or 2MB image, the layout of the firmware device in memory looks
>>>
>>
> 

Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Laszlo Ersek]

On 09/15/20 19:09, Philippe Mathieu-Daudé wrote:
> Hi Laszlo,
> 
> On 9/10/20 8:02 AM, Laszlo Ersek wrote:
>> On 09/09/20 18:21, Philippe Mathieu-Daudé wrote:
>>> On 9/7/20 6:18 PM, Laszlo Ersek wrote:
>>>> In QEMU commit range 4abf70a661a5..69699f3055a5, Phil implemented a QEMU
>>>> facility for exposing the host-side TLS cipher suite configuration to
>>>> OVMF. The purpose is to control the permitted ciphers in the guest's UEFI
>>>> HTTPS boot. This complements the forwarding of the host-side crypto policy
>>>> from the host to the guest -- the other facet was the set of CA
>>>> certificates (for which p11-kit patches had been upstreamed, on the host
>>>> side).
>>>>
>>>> Mention the new command line options in "OvmfPkg/README".
>>>>
>>>> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
>>>> Cc: Gary Lin <glin@suse.com>
>>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>>> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
>>>
>>> Thanks for addressing this BZ for me...
>>>
>>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>>> ---
>>>>  OvmfPkg/README | 24 ++++++++++++--------
>>>>  1 file changed, 15 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/OvmfPkg/README b/OvmfPkg/README
>>>> index 3dd28474ead4..2009d9d29796 100644
>>>> --- a/OvmfPkg/README
>>>> +++ b/OvmfPkg/README
>>>> @@ -294,67 +294,73 @@ and encrypted connection.
>>>>  
>>>>    You can also append a certificate to the existing list with the following
>>>>    command:
>>>>  
>>>>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>>>>  
>>>>    NOTE: You may need the patch to make efisiglist generate the correct header.
>>>>    (https://github.com/rhboot/pesign/pull/40)
>>>>  
>>>>  * Besides the trusted certificates, it's also possible to configure the trusted
>>>>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>>>>  
>>>> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
>>>> -
>>>>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>>>>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>>>>    suite from the intersection of the given list and the built-in cipher
>>>>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>>>>    built-in ones.
>>>>  
>>>> -  While the tool(*5) to create the cipher suite array is still under
>>>> -  development, the array can be generated with the following script:
>>>> +  Using QEMU 5.1 or later, QEMU can expose the ordered list of permitted TLS
>>>> +  cipher suites from the host side to OVMF:
>>>> +
>>>> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
>>>> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
>>>> +
>>>> +  (Refer to the QEMU manual and to
>>>> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
>>>> +  information on the "priority" property.)
>>>> +
>>>> +  Using QEMU 5.0 or earlier, the array has to be passed from a file:
>>>
>>> What about using a '-' to list each "Using QEMU ..." and make the
>>> separation clearer?
>>
>> I can do that, yes. There are three possibilities:
>>
>> - prefix just one line (in each affected paragraph) with the hyphen,
>>
>> - prefix the first line of each paragraph with the hyphen, plus indent
>> the rest of the *same paragraph* by 2 spaces.
> 
> I'd go with this possibility. Clear and easy.
> 
>>
>> - prefix the first line of each paragraph with the hyphen, plus indent
>> the rest of the *text* that applies to the QEMU versions being discussed.
> 
> (Note that would be my *visual* preference, but I don't think it's
> worth it, I prefer we keep the diff short and easy to review).

Agreed on both counts :)

Thanks!
Laszlo

[PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Laszlo Ersek]

In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU
commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the
host-side TLS cipher suite configuration to OVMF. The purpose is to
control the permitted ciphers in the guest's UEFI HTTPS boot. This
complements the forwarding of the host-side crypto policy from the host to
the guest -- the other facet was the set of CA certificates (for which
p11-kit patches had been upstreamed, on the host side).

Mention the new command line options in "OvmfPkg/README".

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---

Notes:
    v2:
    
    - Move the feature boundary from between QEMU 5.0 and 5.1 to 5.1<->5.2
      (the necessary upstream QEMU commit 4318432ccd3f will only be released
      as part of 5.2). Update both the README contents and the commit
      message.
    
    - Indent the "Using QEMU <version>" list entries, and prefix them with a
      hyphen, for better separation. [Phil]
    
    - Pick up Gary's R-b.
    
    - Pick up Phil's R-b.
    
    - Do not pick up Phil's T-b.
    
    Repo:   https://pagure.io/lersek/edk2.git
    Branch: tianocore_2852_v2

 OvmfPkg/README | 24 ++++++++++++--------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/README b/OvmfPkg/README
index 3dd28474ead4..70f0c4152686 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -294,67 +294,73 @@ and encrypted connection.
 
   You can also append a certificate to the existing list with the following
   command:
 
   efisiglist -i <old certdb> -a <cert file> -o <new certdb>
 
   NOTE: You may need the patch to make efisiglist generate the correct header.
   (https://github.com/rhboot/pesign/pull/40)
 
 * Besides the trusted certificates, it's also possible to configure the trusted
   cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
 
-  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
-
   OVMF expects a binary UINT16 array which comprises the cipher suites HEX
   IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
   suite from the intersection of the given list and the built-in cipher
   suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
   built-in ones.
 
-  While the tool(*5) to create the cipher suite array is still under
-  development, the array can be generated with the following script:
+  - Using QEMU 5.2 or later, QEMU can expose the ordered list of permitted TLS
+    cipher suites from the host side to OVMF:
+
+  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
+  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
+
+  (Refer to the QEMU manual and to
+  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
+  information on the "priority" property.)
+
+  - Using QEMU 5.1 or earlier, the array has to be passed from a file:
+
+  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
+
+  whose contents can be generated with the following script, for example:
 
   export LC_ALL=C
   openssl ciphers -V \
   | sed -r -n \
      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
   | xargs -r -- printf -- '%b' > ciphers.bin
 
   This script creates ciphers.bin that contains all the cipher suite IDs
   supported by openssl according to the local host configuration.
 
   You may want to enable only a limited set of cipher suites. Then, you
   should check the validity of your list first:
 
   openssl ciphers -V <cipher list>
 
   If all the cipher suites in your list map to the proper HEX IDs, go ahead
   to modify the script and execute it:
 
   export LC_ALL=C
   openssl ciphers -V <cipher list> \
   | sed -r -n \
      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
   | xargs -r -- printf -- '%b' > ciphers.bin
 
-* In the future (after release 2.12), QEMU should populate both above fw_cfg
-  files automatically from the local host configuration, and enable the user
-  to override either with dedicated options or properties.
-
 (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
 (*2) p11-kit: https://github.com/p11-glue/p11-kit/
 (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
 (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
-(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
 
 === OVMF Flash Layout ===
 
 Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
 appears in QEMU's physical address space just below 4GB (0x100000000).
 
 OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
 FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
 1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
 image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
 
 Using the 1MB or 2MB image, the layout of the firmware device in memory looks
-- 
2.19.1.3.g30247aa5d201

Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding

[Philippe Mathieu-Daudé]

On 9/22/20 11:18 AM, Laszlo Ersek wrote:
> In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU
> commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the
> host-side TLS cipher suite configuration to OVMF. The purpose is to
> control the permitted ciphers in the guest's UEFI HTTPS boot. This
> complements the forwarding of the host-side crypto policy from the host to
> the guest -- the other facet was the set of CA certificates (for which
> p11-kit patches had been upstreamed, on the host side).
> 
> Mention the new command line options in "OvmfPkg/README".
> 
> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
> Cc: Gary Lin <glin@suse.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> Reviewed-by: Gary Lin <glin@suse.com>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> 
> Notes:
>     v2:
>     
>     - Move the feature boundary from between QEMU 5.0 and 5.1 to 5.1<->5.2
>       (the necessary upstream QEMU commit 4318432ccd3f will only be released
>       as part of 5.2). Update both the README contents and the commit
>       message.

:/

Thanks for the updates in v2, all good now.

>     
>     - Indent the "Using QEMU <version>" list entries, and prefix them with a
>       hyphen, for better separation. [Phil]
>     
>     - Pick up Gary's R-b.
>     
>     - Pick up Phil's R-b.
>     
>     - Do not pick up Phil's T-b.
>     
>     Repo:   https://pagure.io/lersek/edk2.git
>     Branch: tianocore_2852_v2
> 
>  OvmfPkg/README | 24 ++++++++++++--------
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 3dd28474ead4..70f0c4152686 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -294,67 +294,73 @@ and encrypted connection.
>  
>    You can also append a certificate to the existing list with the following
>    command:
>  
>    efisiglist -i <old certdb> -a <cert file> -o <new certdb>
>  
>    NOTE: You may need the patch to make efisiglist generate the correct header.
>    (https://github.com/rhboot/pesign/pull/40)
>  
>  * Besides the trusted certificates, it's also possible to configure the trusted
>    cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
>  
> -  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
> -
>    OVMF expects a binary UINT16 array which comprises the cipher suites HEX
>    IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
>    suite from the intersection of the given list and the built-in cipher
>    suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
>    built-in ones.
>  
> -  While the tool(*5) to create the cipher suite array is still under
> -  development, the array can be generated with the following script:
> +  - Using QEMU 5.2 or later, QEMU can expose the ordered list of permitted TLS
> +    cipher suites from the host side to OVMF:
> +
> +  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
> +  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
> +
> +  (Refer to the QEMU manual and to
> +  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
> +  information on the "priority" property.)
> +
> +  - Using QEMU 5.1 or earlier, the array has to be passed from a file:
> +
> +  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
> +
> +  whose contents can be generated with the following script, for example:
>  
>    export LC_ALL=C
>    openssl ciphers -V \
>    | sed -r -n \
>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>    | xargs -r -- printf -- '%b' > ciphers.bin
>  
>    This script creates ciphers.bin that contains all the cipher suite IDs
>    supported by openssl according to the local host configuration.
>  
>    You may want to enable only a limited set of cipher suites. Then, you
>    should check the validity of your list first:
>  
>    openssl ciphers -V <cipher list>
>  
>    If all the cipher suites in your list map to the proper HEX IDs, go ahead
>    to modify the script and execute it:
>  
>    export LC_ALL=C
>    openssl ciphers -V <cipher list> \
>    | sed -r -n \
>       -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
>    | xargs -r -- printf -- '%b' > ciphers.bin
>  
> -* In the future (after release 2.12), QEMU should populate both above fw_cfg
> -  files automatically from the local host configuration, and enable the user
> -  to override either with dedicated options or properties.
> -
>  (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
>  (*2) p11-kit: https://github.com/p11-glue/p11-kit/
>  (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
>  (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
> -(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
>  
>  === OVMF Flash Layout ===
>  
>  Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
>  appears in QEMU's physical address space just below 4GB (0x100000000).
>  
>  OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
>  FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
>  1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
>  image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
>  
>  Using the 1MB or 2MB image, the layout of the firmware device in memory looks
>