Re: [PATCH v2 1/9] OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS boot

[Laszlo Ersek <lersek@redhat.com>]

(comment/question at the end for Ard and Jordan)

On 04/12/18 12:17, Gary Lin wrote:
> On Thu, Apr 12, 2018 at 11:43:35AM +0200, Laszlo Ersek wrote:
>> On 04/12/18 11:10, Gary Lin wrote:
>>> On Thu, Apr 12, 2018 at 10:49:15AM +0200, Laszlo Ersek wrote:
>>>> On 04/12/18 09:08, Gary Lin wrote:
>>>>> On Wed, Apr 11, 2018 at 12:42:39PM +0200, Laszlo Ersek wrote:
>>>>>> Read the list of trusted cipher suites from fw_cfg and to store it to
>>>>>> EFI_TLS_CA_CERTIFICATE_VARIABLE.
>>>>>>
>>>>>> The fw_cfg file is formatted by the "update-crypto-policies" utility on
>>>>>> the host side, so that the host settings take effect in guest HTTPS boot
>>>>>> as well. QEMU forwards the file intact to the firmware. The contents are
>>>>>> forwarded by NetworkPkg/HttpDxe (in TlsConfigCipherList()) to
>>>>>> NetworkPkg/TlsDxe (TlsSetSessionData()) and TlsLib (TlsSetCipherList()).
>>>>>>
>>>>> Hi Laszlo,
>>>>>
>>>>> The description mentioned "update-crypto-policies" to format the cipher
>>>>> list. The command is not available in openSUSE and I downloaded the command
>>>>> from github repo[*]. However, I didn't find any command in the repo
>>>>> could create the binary cipher list.
>>>>
>>>> Right, that feature is underway, and the Crypto team has agreed to
>>>> implement it for me. My apologies for being unclear about it. Until
>>>> then, a small shell script like the following can be used:
>>>>
>>>> -----
>>>> 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
>>>> -----
>>>>
>>> It would be good to have this script in the description or in the README
>>> so that the person who doesn't have the updated update-crypto-policies,
>>> like me, can easily generate the cipher list.
>>
>> I can include this in the commit message, sure.
>>
>> If you think OvmfPkg/README would be a better place for it: can you
>> please submit a patch? ;) It's not just that I'm overloaded (although I
>> am), but I always welcome documentation contributions with enthusiasm.
>> If the documentation captures real life "user stories", that's for the best.
>>
>> You could introduce an "HTTPS Boot" section to the README, between
>> "Network Support" and "OVMF Flash Layout". You contributed quite a bit
>> to HTTPS enablement anyway!
>>
> Sounds good. I'm also thinking about collecting the fw_cfg entries in
> OVMF and documenting them in README. Currently, those entries look like
> black magic to the users.

Indeed, the fw_cfg entries should ultimately not be used by end-users
directly. If that had been the case, I would have chosen different
fw_cfg pathnames. Please refer to the following file under QEMU:

  docs/specs/fw_cfg.txt
  = Externally Provided Items =

That is, if the -fw_cfg cmdline option had been the intended user
interface for this feature, then I would have chosen an "opt/" prefix. I
chose "etc/" because the pathnames are QEMU-defined (not user-defined),
except the QEMU patches will be written later (and it might not be me
either).

It's too bad that the RHBZs that track this feature (across multiple
components) are all private, so I couldn't link them in the blurb and/or
the commit messages. Those RHBZs provide a more comprehensive
background. They are private because... well don't ask me. I didn't make
them private, they got auto-created like that, and I'm sure you know
that, if *you* flip a BZ from private to public, then the burden is on
*you* to defend your decision facing unpredictable parts of your
organization. While I totally disagree with any of these RHBZs being
private, I know better than to make them public myself :)

>> It's up to you, of course :) If you don't have the time, I'll add the
>> script to the commit message.
>>
> I can find some time next week. No guarantee though ;)

Sure, please take your time. (And thank you for taking on the README
update.) Meanwhile I'll push these patches with the commit message
updates discussed.

Ard, Jordan: Gary tested and reviewed this patch (bunch of kudos for
that!), but still, can one of you guys please ACK it too? I prefer the
patch to go in with maintainer blessing. Similarly to commit
9c7d0d499296 ("OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for
HTTPS boot", 2018-03-30).

Thanks!
Laszlo