All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.