qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Laszlo Ersek <lersek@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 12:18:40 +0100	[thread overview]
Message-ID: <20200529111840.GE2755532@redhat.com> (raw)
In-Reply-To: <81c61004-cccc-2ece-91a7-de96012a8ebf@redhat.com>

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

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  parent reply	other threads:[~2020-05-29 11:19 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é [this message]
2020-05-29 12:08       ` Laszlo Ersek
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=20200529111840.GE2755532@redhat.com \
    --to=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@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).