From: Laszlo Ersek <lersek@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [PATCH v7 4/5] crypto: Add tls-cipher-suites object
Date: Fri, 29 May 2020 14:08:54 +0200 [thread overview]
Message-ID: <3ca0c0ec-8b21-d7c5-776f-01502282d821@redhat.com> (raw)
In-Reply-To: <20200529111840.GE2755532@redhat.com>
On 05/29/20 13:18, Daniel P. Berrangé wrote:
> On Fri, May 29, 2020 at 01:09:22PM +0200, Laszlo Ersek wrote:
>> On 05/28/20 19:31, Philippe Mathieu-Daudé wrote:
>> (2) We need an actual commit message for this patch. How about the
>> following -- I have liberally stolen and edited comments that Daniel
>> made earlier in the Red Hat Bugzilla:
>>
>> ---v--- ---v--- ---v--- ---v---
>> On the host OS, various aspects of TLS operation are configurable. In
>> particular it is possible for the sysadmin to control the TLS
>> cipher/protocol algorithms that applications are permitted to use.
>>
>> * Any given crypto library has a built-in default priority list defined by
>> the distro maintainer of the libary package (or by upstream).
>>
>> * The "crypto-policies" RPM (or equivalent host OS package) provides a
>> config file such as "/etc/crypto-policies/config", where the sysadmin
>> can set a high level (library-independent) policy.
>>
>> The "update-crypto-policies --set" command (or equivalent) is used to
>> translate the global policy to individual library representations,
>> producing files such as "/etc/crypto-policies/back-ends/*.config". The
>> generated files, if present, are loaded by the various crypto libraries
>> to override their own built-in defaults.
>>
>> For example, the GNUTLS library may read
>> "/etc/crypto-policies/back-ends/gnutls.config".
>>
>> * A management application (or the QEMU user) may overide the system-wide
>> crypto-policies config via their own config, if they need to diverge
>> from the former.
>>
>> Thus the priority order is "QEMU user config" > "crypto-policies system
>> config" > "library built-in config".
>>
>> Introduce the "tls-cipher-suites" object for exposing the ordered list of
>> permitted TLS cipher suites from the host side to the firmware, via
>> fw_cfg. The list is represented as an array of IANA_TLS_CIPHER objects.
>> The firmware uses the IANA_TLS_CIPHER array for configuring guest-side
>> TLS, for example in UEFI HTTPS Boot.
>>
>> The priority at which the host-side policy is retrieved is given by the
>> "priority" property of the new object type. For example,
>> "priority=@SYSTEM" may be used to refer to
>> "/etc/crypto-policies/back-ends/gnutls.config" (given that QEMU uses
>> GNUTLS).
>> ---^--- ---^--- ---^--- ---^---
>>
>> (3) I think I have now at least formed an idea about where we should
>> document -fw_cfg / "gen_id" in the *manual*.
>>
>> The various -object types are already documented extensively; namely in
>> section "Generic object creation". Thus, I think we should document
>> "tls-cipher-suites" there -- near the already existent "-object tls-*"
>> ones.
>>
>> I suggest including a manual update to that effect. I think we can mostly
>> copy the suggested commit message into the manual as well.
>>
>> And then, we can include the new "-fw_cfg" command line option (with
>> "gen_id") *right there*. Consequently, we won't need to modify the
>> existent "-fw_cfg" documentation bits (about "file" and "string") under
>> section "Debug/Expert options".
>>
>> Dan: please comment!
>
> I don't really have anything else to say. More docs == better
Thanks! Just wanted to be sure I wasn't suggesting something egregious.
Laszlo
next prev parent reply other threads:[~2020-05-29 12:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 17:31 [PATCH v7 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-05-28 17:31 ` [PATCH v7 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-05-29 9:09 ` Laszlo Ersek
2020-05-29 9:21 ` Philippe Mathieu-Daudé
2020-05-28 17:31 ` [PATCH v7 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument Philippe Mathieu-Daudé
2020-05-29 9:50 ` Laszlo Ersek
2020-06-09 14:12 ` Philippe Mathieu-Daudé
2020-06-09 15:50 ` Corey Minyard
2020-06-11 11:31 ` Laszlo Ersek
2020-06-11 11:49 ` Philippe Mathieu-Daudé
2020-06-11 17:54 ` Corey Minyard
2020-06-15 14:45 ` Gerd Hoffmann
2020-06-15 15:02 ` Philippe Mathieu-Daudé
2020-06-16 15:23 ` Laszlo Ersek
2020-05-28 17:31 ` [RFC PATCH v7 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace Philippe Mathieu-Daudé
2020-05-29 10:10 ` Laszlo Ersek
2020-05-28 17:31 ` [PATCH v7 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-05-29 11:09 ` Laszlo Ersek
2020-05-29 11:17 ` Laszlo Ersek
2020-05-29 11:18 ` Daniel P. Berrangé
2020-05-29 12:08 ` Laszlo Ersek [this message]
2020-05-28 17:31 ` [PATCH v7 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob Philippe Mathieu-Daudé
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-all 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=3ca0c0ec-8b21-d7c5-776f-01502282d821@redhat.com \
--to=lersek@redhat.com \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).