[Qemu-commits] [qemu/qemu] 993aec: crypto: Add tls-cipher-suites object

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 993aec27aa39aa90f89f227d8f82cc1f8062386e
      
https://github.com/qemu/qemu/commit/993aec27aa39aa90f89f227d8f82cc1f8062386e
  Author: Philippe Mathieu-Daudé <philmd@redhat.com>
  Date:   2020-07-03 (Fri, 03 Jul 2020)

  Changed paths:
    M crypto/Makefile.objs
    A crypto/tls-cipher-suites.c
    M crypto/trace-events
    A include/crypto/tls-cipher-suites.h
    M qemu-options.hx

  Log Message:
  -----------
  crypto: Add tls-cipher-suites object

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 library 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
guest firmware, via fw_cfg. The list is represented as an array
of bytes.

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).

The firmware uses the IANA_TLS_CIPHER array for configuring
guest-side TLS, for example in UEFI HTTPS Boot.

[Description from Daniel P. Berrangé, edited by Laszlo Ersek.]

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200623172726.21040-2-philmd@redhat.com>


  Commit: 3203148917d035b09f71986ac2eaa19a352d6d9d
      
https://github.com/qemu/qemu/commit/3203148917d035b09f71986ac2eaa19a352d6d9d
  Author: Philippe Mathieu-Daudé <philmd@redhat.com>
  Date:   2020-07-03 (Fri, 03 Jul 2020)

  Changed paths:
    M docs/specs/fw_cfg.txt
    M hw/nvram/fw_cfg.c
    M include/hw/nvram/fw_cfg.h

  Log Message:
  -----------
  hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface

The FW_CFG_DATA_GENERATOR allows any object to produce
blob of data consumable by the fw_cfg device.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200623172726.21040-3-philmd@redhat.com>


  Commit: 6552d87c48679e1ece2da3ddc0947d2146de53ee
      
https://github.com/qemu/qemu/commit/6552d87c48679e1ece2da3ddc0947d2146de53ee
  Author: Philippe Mathieu-Daudé <philmd@redhat.com>
  Date:   2020-07-03 (Fri, 03 Jul 2020)

  Changed paths:
    M softmmu/vl.c

  Log Message:
  -----------
  softmmu/vl: Let -fw_cfg option take a 'gen_id' argument

The 'gen_id' argument refers to a QOM object able to produce
data consumable by the fw_cfg device. The producer object must
implement the FW_CFG_DATA_GENERATOR interface.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200623172726.21040-4-philmd@redhat.com>


  Commit: f7d8afb16dceb780270960692b949329c8752ff2
      
https://github.com/qemu/qemu/commit/f7d8afb16dceb780270960692b949329c8752ff2
  Author: Philippe Mathieu-Daudé <philmd@redhat.com>
  Date:   2020-07-03 (Fri, 03 Jul 2020)

  Changed paths:
    M docs/specs/fw_cfg.txt
    M softmmu/vl.c

  Log Message:
  -----------
  softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace

Names of user-provided fw_cfg items are supposed to start
with "opt/". However FW_CFG_DATA_GENERATOR items are generated
by QEMU, so allow the "etc/" namespace in this specific case.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200623172726.21040-5-philmd@redhat.com>


  Commit: 69699f3055a59e24f1153c329ae6eff4b9a343e0
      
https://github.com/qemu/qemu/commit/69699f3055a59e24f1153c329ae6eff4b9a343e0
  Author: Philippe Mathieu-Daudé <philmd@redhat.com>
  Date:   2020-07-03 (Fri, 03 Jul 2020)

  Changed paths:
    M crypto/tls-cipher-suites.c
    M qemu-options.hx

  Log Message:
  -----------
  crypto/tls-cipher-suites: Produce fw_cfg consumable blob

Since our format is consumable by the fw_cfg device,
we can implement the FW_CFG_DATA_GENERATOR interface.

Example of use to dump the cipher suites (if tracing enabled):

  $ qemu-system-x86_64 -S \
    -object tls-cipher-suites,id=mysuite1,priority=@SYSTEM \
    -fw_cfg name=etc/path/to/ciphers,gen_id=mysuite1 \
    -trace qcrypto\*
  1590664444.197123:qcrypto_tls_cipher_suite_priority priority: @SYSTEM
  1590664444.197219:qcrypto_tls_cipher_suite_info data=[0x13,0x02] 
version=TLS1.3 name=TLS_AES_256_GCM_SHA384
  1590664444.197228:qcrypto_tls_cipher_suite_info data=[0x13,0x03] 
version=TLS1.3 name=TLS_CHACHA20_POLY1305_SHA256
  1590664444.197233:qcrypto_tls_cipher_suite_info data=[0x13,0x01] 
version=TLS1.3 name=TLS_AES_128_GCM_SHA256
  1590664444.197236:qcrypto_tls_cipher_suite_info data=[0x13,0x04] 
version=TLS1.3 name=TLS_AES_128_CCM_SHA256
  1590664444.197240:qcrypto_tls_cipher_suite_info data=[0xc0,0x30] 
version=TLS1.2 name=TLS_ECDHE_RSA_AES_256_GCM_SHA384
  1590664444.197245:qcrypto_tls_cipher_suite_info data=[0xcc,0xa8] 
version=TLS1.2 name=TLS_ECDHE_RSA_CHACHA20_POLY1305
  1590664444.197250:qcrypto_tls_cipher_suite_info data=[0xc0,0x14] 
version=TLS1.0 name=TLS_ECDHE_RSA_AES_256_CBC_SHA1
  1590664444.197254:qcrypto_tls_cipher_suite_info data=[0xc0,0x2f] 
version=TLS1.2 name=TLS_ECDHE_RSA_AES_128_GCM_SHA256
  1590664444.197258:qcrypto_tls_cipher_suite_info data=[0xc0,0x13] 
version=TLS1.0 name=TLS_ECDHE_RSA_AES_128_CBC_SHA1
  1590664444.197261:qcrypto_tls_cipher_suite_info data=[0xc0,0x2c] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
  1590664444.197266:qcrypto_tls_cipher_suite_info data=[0xcc,0xa9] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_CHACHA20_POLY1305
  1590664444.197270:qcrypto_tls_cipher_suite_info data=[0xc0,0xad] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_CCM
  1590664444.197274:qcrypto_tls_cipher_suite_info data=[0xc0,0x0a] 
version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_256_CBC_SHA1
  1590664444.197278:qcrypto_tls_cipher_suite_info data=[0xc0,0x2b] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
  1590664444.197283:qcrypto_tls_cipher_suite_info data=[0xc0,0xac] 
version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_CCM
  1590664444.197287:qcrypto_tls_cipher_suite_info data=[0xc0,0x09] 
version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_128_CBC_SHA1
  1590664444.197291:qcrypto_tls_cipher_suite_info data=[0x00,0x9d] 
version=TLS1.2 name=TLS_RSA_AES_256_GCM_SHA384
  1590664444.197296:qcrypto_tls_cipher_suite_info data=[0xc0,0x9d] 
version=TLS1.2 name=TLS_RSA_AES_256_CCM
  1590664444.197300:qcrypto_tls_cipher_suite_info data=[0x00,0x35] 
version=TLS1.0 name=TLS_RSA_AES_256_CBC_SHA1
  1590664444.197304:qcrypto_tls_cipher_suite_info data=[0x00,0x9c] 
version=TLS1.2 name=TLS_RSA_AES_128_GCM_SHA256
  1590664444.197308:qcrypto_tls_cipher_suite_info data=[0xc0,0x9c] 
version=TLS1.2 name=TLS_RSA_AES_128_CCM
  1590664444.197312:qcrypto_tls_cipher_suite_info data=[0x00,0x2f] 
version=TLS1.0 name=TLS_RSA_AES_128_CBC_SHA1
  1590664444.197316:qcrypto_tls_cipher_suite_info data=[0x00,0x9f] 
version=TLS1.2 name=TLS_DHE_RSA_AES_256_GCM_SHA384
  1590664444.197320:qcrypto_tls_cipher_suite_info data=[0xcc,0xaa] 
version=TLS1.2 name=TLS_DHE_RSA_CHACHA20_POLY1305
  1590664444.197325:qcrypto_tls_cipher_suite_info data=[0xc0,0x9f] 
version=TLS1.2 name=TLS_DHE_RSA_AES_256_CCM
  1590664444.197329:qcrypto_tls_cipher_suite_info data=[0x00,0x39] 
version=TLS1.0 name=TLS_DHE_RSA_AES_256_CBC_SHA1
  1590664444.197333:qcrypto_tls_cipher_suite_info data=[0x00,0x9e] 
version=TLS1.2 name=TLS_DHE_RSA_AES_128_GCM_SHA256
  1590664444.197337:qcrypto_tls_cipher_suite_info data=[0xc0,0x9e] 
version=TLS1.2 name=TLS_DHE_RSA_AES_128_CCM
  1590664444.197341:qcrypto_tls_cipher_suite_info data=[0x00,0x33] 
version=TLS1.0 name=TLS_DHE_RSA_AES_128_CBC_SHA1
  1590664444.197345:qcrypto_tls_cipher_suite_count count: 29

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200623172726.21040-6-philmd@redhat.com>


  Commit: aecdfcc3f8499b34a90e5b21159b4d245bc833c2
      
https://github.com/qemu/qemu/commit/aecdfcc3f8499b34a90e5b21159b4d245bc833c2
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2020-07-09 (Thu, 09 Jul 2020)

  Changed paths:
    M crypto/Makefile.objs
    A crypto/tls-cipher-suites.c
    M crypto/trace-events
    M docs/specs/fw_cfg.txt
    M hw/nvram/fw_cfg.c
    A include/crypto/tls-cipher-suites.h
    M include/hw/nvram/fw_cfg.h
    M qemu-options.hx
    M softmmu/vl.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/philmd-gitlab/tags/fw_cfg-20200704' 
into staging

firmware (and crypto) patches

- add the tls-cipher-suites object,
- add the ability to QOM objects to produce data consumable
  by the fw_cfg device,
- let the tls-cipher-suites object implement the
  FW_CFG_DATA_GENERATOR interface.

This is required by EDK2 'HTTPS Boot' feature of OVMF to tell
the guest which TLS ciphers it can use.

CI jobs results:
  https://travis-ci.org/github/philmd/qemu/builds/704724619
  https://gitlab.com/philmd/qemu/-/pipelines/162938106
  https://cirrus-ci.com/build/4682977303068672

# gpg: Signature made Sat 04 Jul 2020 17:37:08 BST
# gpg:                using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" 
[full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD  6BB2 E3E3 2C2C DEAD C0DE

* remotes/philmd-gitlab/tags/fw_cfg-20200704:
  crypto/tls-cipher-suites: Produce fw_cfg consumable blob
  softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace
  softmmu/vl: Let -fw_cfg option take a 'gen_id' argument
  hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
  crypto: Add tls-cipher-suites object

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/aff2caf6b3fb...aecdfcc3f849