| Message ID | 20200704163927.28188-6-philmd@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PULL,1/5] crypto: Add tls-cipher-suites object | expand |
Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben: > 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> I noticed only now that this breaks '--object help' in qemu-storage-daemon: $ qemu-storage-daemon --object help List of user creatable objects: qemu-storage-daemon: missing interface 'fw_cfg-data-generator' for object 'tls-creds' Aborted (core dumped) The reason is that we don't (and can't) link hw/nvram/fw_cfg.c into the storage daemon because it requires other system emulator stuff. Kevin
On 09/29/20 17:46, Kevin Wolf wrote: > Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben: >> 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> > > I noticed only now that this breaks '--object help' in > qemu-storage-daemon: > > $ qemu-storage-daemon --object help > List of user creatable objects: > qemu-storage-daemon: missing interface 'fw_cfg-data-generator' for object 'tls-creds' > Aborted (core dumped) > > The reason is that we don't (and can't) link hw/nvram/fw_cfg.c into the > storage daemon because it requires other system emulator stuff. Ouch. I've been completely oblivious to "--object help" and how it affects qemu-storage-daemon. Sorry about that. Could you please include a backtrace about the abort()? Grepping for the error message, I can find type_initialize() in "qom/object.c", but my knowledge about QOM internals is practically nil. The error message seems bogus FWIW -- why would TYPE_FW_CFG_DATA_GENERATOR_INTERFACE be *required* from "tls-creds"? TYPE_FW_CFG_DATA_GENERATOR_INTERFACE is implemented by "tls-cipher-suites", and required by "-fw_cfg name=...,gen_id=...". If that -fw_cfg switch is not used, then why would anything look for the TYPE_FW_CFG_DATA_GENERATOR_INTERFACE interface? Especially under the tls-creds object? Thanks, Laszlo
Hi Laszlo, On 10/1/20 9:18 AM, Laszlo Ersek wrote: > On 09/29/20 17:46, Kevin Wolf wrote: >> Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben: >>> 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> >> >> I noticed only now that this breaks '--object help' in >> qemu-storage-daemon: >> >> $ qemu-storage-daemon --object help >> List of user creatable objects: >> qemu-storage-daemon: missing interface 'fw_cfg-data-generator' for object 'tls-creds' >> Aborted (core dumped) >> >> The reason is that we don't (and can't) link hw/nvram/fw_cfg.c into the >> storage daemon because it requires other system emulator stuff. > > Ouch. I've been completely oblivious to "--object help" and how it > affects qemu-storage-daemon. Sorry about that. > > Could you please include a backtrace about the abort()? > > Grepping for the error message, I can find type_initialize() in > "qom/object.c", but my knowledge about QOM internals is practically nil. > > The error message seems bogus FWIW -- why would > TYPE_FW_CFG_DATA_GENERATOR_INTERFACE be *required* from "tls-creds"? > > TYPE_FW_CFG_DATA_GENERATOR_INTERFACE is implemented by > "tls-cipher-suites", and required by "-fw_cfg name=...,gen_id=...". If > that -fw_cfg switch is not used, then why would anything look for the > TYPE_FW_CFG_DATA_GENERATOR_INTERFACE interface? Especially under the > tls-creds object? Sorry for not updating Kevin's post in time (we have been discussing over IRC). What happens here is a QOM design flow, first triggered by fw_cfg as we are now trying to have QEMU split into more components. QOM interface/object type names are simple strings, so we don't get any link failure in case of missing dependency (which are resolved at runtime using strcmp). "tls-cipher-suites" is a generic crypto object, it happens to implement the fw_cfg-data-generator interface. The fw_cfg-data-generator interface is registered as QOM type in hw/nvram/fw_cfg.c which is only built when SOFTMMU is selected. qemu-storage-daemon doesn't select SOFTMMU. We don't want to restrict "tls-cipher-suites" to SOFTMMU. The simplest fix we discuss is to have a single C file to register the fw_cfg-data-generator interface in QOM, and link with it if any of CRYPTO / NVRAM kconfig is selected. I'll send a patch. Regards, Phil.
On 10/05/20 11:16, Philippe Mathieu-Daudé wrote: > Hi Laszlo, > > On 10/1/20 9:18 AM, Laszlo Ersek wrote: >> On 09/29/20 17:46, Kevin Wolf wrote: >>> Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben: >>>> 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> >>> >>> I noticed only now that this breaks '--object help' in >>> qemu-storage-daemon: >>> >>> $ qemu-storage-daemon --object help >>> List of user creatable objects: >>> qemu-storage-daemon: missing interface 'fw_cfg-data-generator' for object 'tls-creds' >>> Aborted (core dumped) >>> >>> The reason is that we don't (and can't) link hw/nvram/fw_cfg.c into the >>> storage daemon because it requires other system emulator stuff. >> >> Ouch. I've been completely oblivious to "--object help" and how it >> affects qemu-storage-daemon. Sorry about that. >> >> Could you please include a backtrace about the abort()? >> >> Grepping for the error message, I can find type_initialize() in >> "qom/object.c", but my knowledge about QOM internals is practically nil. >> >> The error message seems bogus FWIW -- why would >> TYPE_FW_CFG_DATA_GENERATOR_INTERFACE be *required* from "tls-creds"? >> >> TYPE_FW_CFG_DATA_GENERATOR_INTERFACE is implemented by >> "tls-cipher-suites", and required by "-fw_cfg name=...,gen_id=...". If >> that -fw_cfg switch is not used, then why would anything look for the >> TYPE_FW_CFG_DATA_GENERATOR_INTERFACE interface? Especially under the >> tls-creds object? > > Sorry for not updating Kevin's post in time (we have been discussing > over IRC). > > What happens here is a QOM design flow, first triggered by fw_cfg as > we are now trying to have QEMU split into more components. > > QOM interface/object type names are simple strings, so we don't get > any link failure in case of missing dependency (which are resolved at > runtime using strcmp). > > "tls-cipher-suites" is a generic crypto object, it happens to implement > the fw_cfg-data-generator interface. The fw_cfg-data-generator interface > is registered as QOM type in hw/nvram/fw_cfg.c which is only built when > SOFTMMU is selected. qemu-storage-daemon doesn't select SOFTMMU. > We don't want to restrict "tls-cipher-suites" to SOFTMMU. > > The simplest fix we discuss is to have a single C file to register the > fw_cfg-data-generator interface in QOM, and link with it if any of > CRYPTO / NVRAM kconfig is selected. > > I'll send a patch. Thank you for the explanation! (I suggest keeping such discussions *originally* on the list. IRC is practically indistinguishable from the bit bucket, and you'll have to write up a summary for others on the mailing list anyway. (In some cases it could even require filing a ticket in some tracker, in the end.) Best to have the discussion at once on the list. Just my suggestion of course.) Thanks! Laszlo
On 10/6/20 10:41 AM, Laszlo Ersek wrote: > On 10/05/20 11:16, Philippe Mathieu-Daudé wrote: >> Hi Laszlo, >> >> On 10/1/20 9:18 AM, Laszlo Ersek wrote: >>> On 09/29/20 17:46, Kevin Wolf wrote: >>>> Am 04.07.2020 um 18:39 hat Philippe Mathieu-Daudé geschrieben: >>>>> 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> >>>> >>>> I noticed only now that this breaks '--object help' in >>>> qemu-storage-daemon: >>>> >>>> $ qemu-storage-daemon --object help >>>> List of user creatable objects: >>>> qemu-storage-daemon: missing interface 'fw_cfg-data-generator' for object 'tls-creds' >>>> Aborted (core dumped) >>>> >>>> The reason is that we don't (and can't) link hw/nvram/fw_cfg.c into the >>>> storage daemon because it requires other system emulator stuff. >>> >>> Ouch. I've been completely oblivious to "--object help" and how it >>> affects qemu-storage-daemon. Sorry about that. >>> >>> Could you please include a backtrace about the abort()? >>> >>> Grepping for the error message, I can find type_initialize() in >>> "qom/object.c", but my knowledge about QOM internals is practically nil. >>> >>> The error message seems bogus FWIW -- why would >>> TYPE_FW_CFG_DATA_GENERATOR_INTERFACE be *required* from "tls-creds"? >>> >>> TYPE_FW_CFG_DATA_GENERATOR_INTERFACE is implemented by >>> "tls-cipher-suites", and required by "-fw_cfg name=...,gen_id=...". If >>> that -fw_cfg switch is not used, then why would anything look for the >>> TYPE_FW_CFG_DATA_GENERATOR_INTERFACE interface? Especially under the >>> tls-creds object? >> >> Sorry for not updating Kevin's post in time (we have been discussing >> over IRC). >> >> What happens here is a QOM design flow, first triggered by fw_cfg as >> we are now trying to have QEMU split into more components. >> >> QOM interface/object type names are simple strings, so we don't get >> any link failure in case of missing dependency (which are resolved at >> runtime using strcmp). >> >> "tls-cipher-suites" is a generic crypto object, it happens to implement >> the fw_cfg-data-generator interface. The fw_cfg-data-generator interface >> is registered as QOM type in hw/nvram/fw_cfg.c which is only built when >> SOFTMMU is selected. qemu-storage-daemon doesn't select SOFTMMU. >> We don't want to restrict "tls-cipher-suites" to SOFTMMU. >> >> The simplest fix we discuss is to have a single C file to register the >> fw_cfg-data-generator interface in QOM, and link with it if any of >> CRYPTO / NVRAM kconfig is selected. >> >> I'll send a patch. > > Thank you for the explanation! > > (I suggest keeping such discussions *originally* on the list. IRC is > practically indistinguishable from the bit bucket, and you'll have to > write up a summary for others on the mailing list anyway. (In some cases > it could even require filing a ticket in some tracker, in the end.) Best > to have the discussion at once on the list. Just my suggestion of course.) There are so many discussions there... But you are right, noted for the areas I'm co-maintaining, I'll summarize on the list. Regards, Phil.
diff --git a/crypto/tls-cipher-suites.c b/crypto/tls-cipher-suites.c index a4e0f84307..0d305b684b 100644 --- a/crypto/tls-cipher-suites.c +++ b/crypto/tls-cipher-suites.c @@ -13,6 +13,7 @@ #include "qom/object_interfaces.h" #include "crypto/tlscreds.h" #include "crypto/tls-cipher-suites.h" +#include "hw/nvram/fw_cfg.h" #include "trace.h" /* @@ -88,11 +89,20 @@ static void qcrypto_tls_cipher_suites_complete(UserCreatable *uc, } } +static GByteArray *qcrypto_tls_cipher_suites_fw_cfg_gen_data(Object *obj, + Error **errp) +{ + return qcrypto_tls_cipher_suites_get_data(QCRYPTO_TLS_CIPHER_SUITES(obj), + errp); +} + static void qcrypto_tls_cipher_suites_class_init(ObjectClass *oc, void *data) { UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc); + FWCfgDataGeneratorClass *fwgc = FW_CFG_DATA_GENERATOR_CLASS(oc); ucc->complete = qcrypto_tls_cipher_suites_complete; + fwgc->get_data = qcrypto_tls_cipher_suites_fw_cfg_gen_data; } static const TypeInfo qcrypto_tls_cipher_suites_info = { @@ -103,6 +113,7 @@ static const TypeInfo qcrypto_tls_cipher_suites_info = { .class_init = qcrypto_tls_cipher_suites_class_init, .interfaces = (InterfaceInfo[]) { { TYPE_USER_CREATABLE }, + { TYPE_FW_CFG_DATA_GENERATOR_INTERFACE }, { } } }; diff --git a/qemu-options.hx b/qemu-options.hx index ecc4658e1f..b2cbbbf281 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4586,6 +4586,24 @@ SRST string as described at https://gnutls.org/manual/html_node/Priority-Strings.html. + An example of use of this object is to control UEFI HTTPS Boot. + The tls-cipher-suites object exposes 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 IANA_TLS_CIPHER + objects. The firmware uses the IANA_TLS_CIPHER array for configuring + guest-side TLS. + + In the following example, the priority at which the host-side policy + is retrieved is given by the ``priority`` property. + Given that QEMU uses GNUTLS, ``priority=@SYSTEM`` may be used to + refer to /etc/crypto-policies/back-ends/gnutls.config. + + .. parsed-literal:: + + # |qemu_system| \ + -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \ + -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0 + ``-object filter-buffer,id=id,netdev=netdevid,interval=t[,queue=all|rx|tx][,status=on|off][,position=head|tail|id=<id>][,insert=behind|before]`` Interval t can't be 0, this filter batches the packet delivery: all packets arriving in a given interval on netdev netdevid are
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> --- crypto/tls-cipher-suites.c | 11 +++++++++++ qemu-options.hx | 18 ++++++++++++++++++ 2 files changed, 29 insertions(+)