* [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites
@ 2020-06-15 10:34 Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
` (4 more replies)
0 siblings, 5 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-15 10:34 UTC (permalink / raw)
To: qemu-devel, Gerd Hoffmann
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Laszlo Ersek, Paolo Bonzini
Hi,
This series has two parts:
- First we add the ability to QOM objects to produce data
consumable by the fw_cfg device,
- Then we add the tls-cipher-suites object, and let it
implement the FW_CFG_DATA_GENERATOR interface.
This is required by EDK2 'HTTPS Boot' feature [*] to tell
the guest which TLS ciphers it can use.
** Unresolved item: **
- Should a generated fw_cfg entry use a specific global order?
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02309.html
^ Gerd can you help?
Daniel, can you review/ack?
Since v8:
- addressed Laszlo review comments (reword/typos)
Since v7:
- addressed Laszlo review comments
Since v6:
- addressed Laszlo & Daniel review comments
Since v5:
- Complete rewrite after chatting with Daniel Berrangé
Since v4:
- Addressed Laszlo comments (see patch#1 description)
Since v3:
- Addressed Markus' comments (do not care about heap)
Since v2:
- Split of
Since v1:
- Addressed Michael and Laszlo comments.
Phil.
[*]: https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
v8: https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02428.html
v7: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08050.html
v6: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05448.html
v5: https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04525.html
v4: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg04300.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02965.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02522.html
v1: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg01598.html
Philippe Mathieu-Daudé (5):
hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
softmmu/vl: Let -fw_cfg option take a 'gen_id' argument
softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace
crypto: Add tls-cipher-suites object
crypto/tls-cipher-suites: Produce fw_cfg consumable blob
docs/specs/fw_cfg.txt | 13 ++-
include/crypto/tls-cipher-suites.h | 38 ++++++++
include/hw/nvram/fw_cfg.h | 52 ++++++++++
crypto/tls-cipher-suites.c | 146 +++++++++++++++++++++++++++++
hw/nvram/fw_cfg.c | 36 +++++++
softmmu/vl.c | 33 +++++--
crypto/Makefile.objs | 1 +
crypto/trace-events | 5 +
qemu-options.hx | 37 ++++++++
9 files changed, 351 insertions(+), 10 deletions(-)
create mode 100644 include/crypto/tls-cipher-suites.h
create mode 100644 crypto/tls-cipher-suites.c
--
2.21.3
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
@ 2020-06-15 10:34 ` Philippe Mathieu-Daudé
2020-06-16 15:31 ` Daniel P. Berrangé
2020-06-15 10:34 ` [PATCH v9 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument Philippe Mathieu-Daudé
` (3 subsequent siblings)
4 siblings, 1 reply; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-15 10:34 UTC (permalink / raw)
To: qemu-devel, Gerd Hoffmann
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Laszlo Ersek, Paolo Bonzini
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>
---
docs/specs/fw_cfg.txt | 9 ++++++-
include/hw/nvram/fw_cfg.h | 52 +++++++++++++++++++++++++++++++++++++++
hw/nvram/fw_cfg.c | 36 +++++++++++++++++++++++++++
3 files changed, 96 insertions(+), 1 deletion(-)
diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index 8f1ebc66fa..bc16daa38a 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -219,7 +219,7 @@ To check the result, read the "control" field:
= Externally Provided Items =
-As of v2.4, "file" fw_cfg items (i.e., items with selector keys above
+Since v2.4, "file" fw_cfg items (i.e., items with selector keys above
FW_CFG_FILE_FIRST, and with a corresponding entry in the fw_cfg file
directory structure) may be inserted via the QEMU command line, using
the following syntax:
@@ -230,6 +230,13 @@ Or
-fw_cfg [name=]<item_name>,string=<string>
+Since v5.1, QEMU allows some objects to generate fw_cfg-specific content,
+the content is then associated with a "file" item using the 'gen_id' option
+in the command line, using the following syntax:
+
+ -object <generator-type>,id=<generated_id>,[generator-specific-options] \
+ -fw_cfg [name=]<item_name>,gen_id=<generated_id>
+
See QEMU man page for more documentation.
Using item_name with plain ASCII characters only is recommended.
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 25d9307018..ca69666847 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -9,11 +9,43 @@
#define TYPE_FW_CFG "fw_cfg"
#define TYPE_FW_CFG_IO "fw_cfg_io"
#define TYPE_FW_CFG_MEM "fw_cfg_mem"
+#define TYPE_FW_CFG_DATA_GENERATOR_INTERFACE "fw_cfg-data-generator"
#define FW_CFG(obj) OBJECT_CHECK(FWCfgState, (obj), TYPE_FW_CFG)
#define FW_CFG_IO(obj) OBJECT_CHECK(FWCfgIoState, (obj), TYPE_FW_CFG_IO)
#define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
+#define FW_CFG_DATA_GENERATOR_CLASS(class) \
+ OBJECT_CLASS_CHECK(FWCfgDataGeneratorClass, (class), \
+ TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
+#define FW_CFG_DATA_GENERATOR_GET_CLASS(obj) \
+ OBJECT_GET_CLASS(FWCfgDataGeneratorClass, (obj), \
+ TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
+
+typedef struct FWCfgDataGeneratorClass {
+ /*< private >*/
+ InterfaceClass parent_class;
+ /*< public >*/
+
+ /**
+ * get_data:
+ * @obj: the object implementing this interface
+ *
+ * Returns: pointer to start of the generated item data
+ *
+ * The returned pointer is a QObject weak reference, @obj owns
+ * the reference and may free it at any time in the future.
+ */
+ const void *(*get_data)(Object *obj);
+ /**
+ * get_length:
+ * @obj: the object implementing this interface
+ *
+ * Returns: the size of the generated item data in bytes
+ */
+ size_t (*get_length)(Object *obj);
+} FWCfgDataGeneratorClass;
+
typedef struct fw_cfg_file FWCfgFile;
#define FW_CFG_ORDER_OVERRIDE_VGA 70
@@ -263,6 +295,26 @@ void fw_cfg_add_file_callback(FWCfgState *s, const char *filename,
void *fw_cfg_modify_file(FWCfgState *s, const char *filename, void *data,
size_t len);
+/**
+ * fw_cfg_add_from_generator:
+ * @s: fw_cfg device being modified
+ * @filename: name of new fw_cfg file item
+ * @gen_id: name of object implementing FW_CFG_DATA_GENERATOR interface
+ * @errp: pointer to a NULL initialized error object
+ *
+ * Add a new NAMED fw_cfg item with the content generated from the
+ * @gen_id object. The data generated by the @gen_id object is copied
+ * into the data structure of the fw_cfg device.
+ * The next available (unused) selector key starting at FW_CFG_FILE_FIRST
+ * will be used; also, a new entry will be added to the file directory
+ * structure residing at key value FW_CFG_FILE_DIR, containing the item name,
+ * data size, and assigned selector key value.
+ *
+ * Returns: the size of the generated item data on success, or 0 on errors.
+ */
+size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
+ const char *gen_id, Error **errp);
+
FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
AddressSpace *dma_as);
FWCfgState *fw_cfg_init_io(uint32_t iobase);
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 8dd50c2c72..84578e83aa 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -1032,6 +1032,36 @@ void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
return NULL;
}
+size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
+ const char *gen_id, Error **errp)
+{
+ FWCfgDataGeneratorClass *klass;
+ Object *obj;
+ size_t size;
+
+ obj = object_resolve_path_component(object_get_objects_root(), gen_id);
+ if (!obj) {
+ error_setg(errp, "Cannot find object ID '%s'", gen_id);
+ return 0;
+ }
+ if (!object_dynamic_cast(obj, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)) {
+ error_setg(errp, "Object ID '%s' is not a '%s' subclass",
+ gen_id, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE);
+ return 0;
+ }
+ klass = FW_CFG_DATA_GENERATOR_GET_CLASS(obj);
+ size = klass->get_length(obj);
+ if (size == 0) {
+ error_setg(errp, "Object ID '%s' failed to generate fw_cfg data",
+ gen_id);
+ return 0;
+ }
+ fw_cfg_add_file(s, filename, g_memdup(klass->get_data(obj), (guint)size),
+ size);
+
+ return size;
+}
+
static void fw_cfg_machine_reset(void *opaque)
{
MachineClass *mc = MACHINE_GET_CLASS(qdev_get_machine());
@@ -1333,12 +1363,18 @@ static const TypeInfo fw_cfg_mem_info = {
.class_init = fw_cfg_mem_class_init,
};
+static const TypeInfo fw_cfg_data_generator_interface_info = {
+ .name = TYPE_FW_CFG_DATA_GENERATOR_INTERFACE,
+ .parent = TYPE_INTERFACE,
+ .class_size = sizeof(FWCfgDataGeneratorClass),
+};
static void fw_cfg_register_types(void)
{
type_register_static(&fw_cfg_info);
type_register_static(&fw_cfg_io_info);
type_register_static(&fw_cfg_mem_info);
+ type_register_static(&fw_cfg_data_generator_interface_info);
}
type_init(fw_cfg_register_types)
--
2.21.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v9 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
@ 2020-06-15 10:34 ` Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace Philippe Mathieu-Daudé
` (2 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-15 10:34 UTC (permalink / raw)
To: qemu-devel, Gerd Hoffmann
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Laszlo Ersek, Paolo Bonzini
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>
---
softmmu/vl.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/softmmu/vl.c b/softmmu/vl.c
index f669c06ede..a46fe5c6c9 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -489,6 +489,11 @@ static QemuOptsList qemu_fw_cfg_opts = {
.name = "string",
.type = QEMU_OPT_STRING,
.help = "Sets content of the blob to be inserted from a string",
+ }, {
+ .name = "gen_id",
+ .type = QEMU_OPT_STRING,
+ .help = "Sets id of the object generating the fw_cfg blob "
+ "to be inserted",
},
{ /* end of list */ }
},
@@ -2020,7 +2025,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
{
gchar *buf;
size_t size;
- const char *name, *file, *str;
+ const char *name, *file, *str, *gen_id;
FWCfgState *fw_cfg = (FWCfgState *) opaque;
if (fw_cfg == NULL) {
@@ -2030,14 +2035,13 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
name = qemu_opt_get(opts, "name");
file = qemu_opt_get(opts, "file");
str = qemu_opt_get(opts, "string");
+ gen_id = qemu_opt_get(opts, "gen_id");
- /* we need name and either a file or the content string */
- if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str)))) {
- error_setg(errp, "invalid argument(s)");
- return -1;
- }
- if (nonempty_str(file) && nonempty_str(str)) {
- error_setg(errp, "file and string are mutually exclusive");
+ /* we need the name, and exactly one of: file, content string, gen_id */
+ if (!nonempty_str(name) ||
+ nonempty_str(file) + nonempty_str(str) + nonempty_str(gen_id) != 1) {
+ error_setg(errp, "name, plus exactly one of file,"
+ " string and gen_id, are needed");
return -1;
}
if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
@@ -2052,6 +2056,11 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
if (nonempty_str(str)) {
size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
buf = g_memdup(str, size);
+ } else if (nonempty_str(gen_id)) {
+ size_t fw_cfg_size;
+
+ fw_cfg_size = fw_cfg_add_from_generator(fw_cfg, name, gen_id, errp);
+ return (fw_cfg_size > 0) ? 0 : -1;
} else {
GError *err = NULL;
if (!g_file_get_contents(file, &buf, &size, &err)) {
--
2.21.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v9 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument Philippe Mathieu-Daudé
@ 2020-06-15 10:34 ` Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob Philippe Mathieu-Daudé
4 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-15 10:34 UTC (permalink / raw)
To: qemu-devel, Gerd Hoffmann
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Laszlo Ersek, Paolo Bonzini
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>
---
docs/specs/fw_cfg.txt | 4 ++++
softmmu/vl.c | 8 +++++++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index bc16daa38a..3e6d586f66 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.txt
@@ -258,4 +258,8 @@ Prefix "opt/org.qemu/" is reserved for QEMU itself.
Use of names not beginning with "opt/" is potentially dangerous and
entirely unsupported. QEMU will warn if you try.
+Use of names not beginning with "opt/" is tolerated with 'gen_id' (that
+is, the warning is suppressed), but you must know exactly what you're
+doing.
+
All externally provided fw_cfg items are read-only to the guest.
diff --git a/softmmu/vl.c b/softmmu/vl.c
index a46fe5c6c9..535f9d4f24 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2049,7 +2049,13 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts, Error **errp)
FW_CFG_MAX_FILE_PATH - 1);
return -1;
}
- if (strncmp(name, "opt/", 4) != 0) {
+ if (nonempty_str(gen_id)) {
+ /*
+ * In this particular case where the content is populated
+ * internally, the "etc/" namespace protection is relaxed,
+ * so do not emit a warning.
+ */
+ } else if (strncmp(name, "opt/", 4) != 0) {
warn_report("externally provided fw_cfg item names "
"should be prefixed with \"opt/\"");
}
--
2.21.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v9 4/5] crypto: Add tls-cipher-suites object
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
` (2 preceding siblings ...)
2020-06-15 10:34 ` [PATCH v9 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace Philippe Mathieu-Daudé
@ 2020-06-15 10:34 ` Philippe Mathieu-Daudé
2020-06-16 16:32 ` Daniel P. Berrangé
2020-06-15 10:34 ` [PATCH v9 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob Philippe Mathieu-Daudé
4 siblings, 1 reply; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-15 10:34 UTC (permalink / raw)
To: qemu-devel, Gerd Hoffmann
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Laszlo Ersek, Paolo Bonzini
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 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).
[Description from Daniel P. Berrangé, edited by Laszlo Ersek.]
Example of use to dump the cipher suites:
$ qemu-system-x86_64 -S \
-object tls-cipher-suites,id=mysuite,priority=@SYSTEM \
-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
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
v9: Replaced 'backends' -> 'frontends' (lersek)
---
include/crypto/tls-cipher-suites.h | 38 +++++++++
crypto/tls-cipher-suites.c | 127 +++++++++++++++++++++++++++++
crypto/Makefile.objs | 1 +
crypto/trace-events | 5 ++
qemu-options.hx | 19 +++++
5 files changed, 190 insertions(+)
create mode 100644 include/crypto/tls-cipher-suites.h
create mode 100644 crypto/tls-cipher-suites.c
diff --git a/include/crypto/tls-cipher-suites.h b/include/crypto/tls-cipher-suites.h
new file mode 100644
index 0000000000..3848393a20
--- /dev/null
+++ b/include/crypto/tls-cipher-suites.h
@@ -0,0 +1,38 @@
+/*
+ * QEMU TLS Cipher Suites Registry (RFC8447)
+ *
+ * Copyright (c) 2019 Red Hat, Inc.
+ *
+ * Author: Philippe Mathieu-Daudé <philmd@redhat.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#ifndef QCRYPTO_TLSCIPHERSUITES_H
+#define QCRYPTO_TLSCIPHERSUITES_H
+
+#include "qom/object.h"
+#include "crypto/tlscreds.h"
+
+#define TYPE_QCRYPTO_TLS_CIPHER_SUITES "tls-cipher-suites"
+#define QCRYPTO_TLS_CIPHER_SUITES(obj) \
+ OBJECT_CHECK(QCryptoTLSCipherSuites, (obj), TYPE_QCRYPTO_TLS_CIPHER_SUITES)
+
+/*
+ * IANA registered TLS ciphers:
+ * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
+ */
+typedef struct {
+ uint8_t data[2];
+} QEMU_PACKED IANA_TLS_CIPHER;
+
+typedef struct QCryptoTLSCipherSuites {
+ /* <private> */
+ QCryptoTLSCreds parent_obj;
+
+ /* <public> */
+ IANA_TLS_CIPHER *cipher_list;
+ unsigned cipher_count;
+} QCryptoTLSCipherSuites;
+
+#endif /* QCRYPTO_TLSCIPHERSUITES_H */
diff --git a/crypto/tls-cipher-suites.c b/crypto/tls-cipher-suites.c
new file mode 100644
index 0000000000..f02a041f9a
--- /dev/null
+++ b/crypto/tls-cipher-suites.c
@@ -0,0 +1,127 @@
+/*
+ * QEMU TLS Cipher Suites
+ *
+ * Copyright (c) 2019 Red Hat, Inc.
+ *
+ * Author: Philippe Mathieu-Daudé <philmd@redhat.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qom/object_interfaces.h"
+#include "qemu/error-report.h"
+#include "crypto/tlscreds.h"
+#include "crypto/tls-cipher-suites.h"
+#include "trace.h"
+
+static void parse_cipher_suites(QCryptoTLSCipherSuites *s,
+ const char *priority_name, Error **errp)
+{
+ int ret;
+ const char *err;
+ gnutls_priority_t pcache;
+ enum { M_ENUMERATE, M_GENERATE, M_DONE } mode;
+
+ assert(priority_name);
+ trace_qcrypto_tls_cipher_suite_priority(priority_name);
+ ret = gnutls_priority_init(&pcache, priority_name, &err);
+ if (ret < 0) {
+ error_setg(errp, "Syntax error using priority '%s': %s",
+ priority_name, gnutls_strerror(ret));
+ return;
+ }
+
+ for (mode = M_ENUMERATE; mode < M_DONE; mode++) {
+ size_t i;
+
+ for (i = 0;; i++) {
+ int ret;
+ unsigned idx;
+ const char *name;
+ IANA_TLS_CIPHER cipher;
+ gnutls_protocol_t protocol;
+
+ ret = gnutls_priority_get_cipher_suite_index(pcache, i, &idx);
+ if (ret == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
+ break;
+ }
+ if (ret == GNUTLS_E_UNKNOWN_CIPHER_SUITE) {
+ continue;
+ }
+
+ name = gnutls_cipher_suite_info(idx, (unsigned char *)&cipher,
+ NULL, NULL, NULL, &protocol);
+ if (name == NULL) {
+ continue;
+ }
+
+ if (mode == M_GENERATE) {
+ const char *version;
+
+ version = gnutls_protocol_get_name(protocol);
+ trace_qcrypto_tls_cipher_suite_info(cipher.data[0],
+ cipher.data[1],
+ version, name);
+ s->cipher_list[s->cipher_count] = cipher;
+ }
+ s->cipher_count++;
+ }
+
+ if (mode == M_ENUMERATE) {
+ if (s->cipher_count == 0) {
+ break;
+ }
+ s->cipher_list = g_new(IANA_TLS_CIPHER, s->cipher_count);
+ s->cipher_count = 0;
+ }
+ }
+ trace_qcrypto_tls_cipher_suite_count(s->cipher_count);
+ gnutls_priority_deinit(pcache);
+}
+
+static void qcrypto_tls_cipher_suites_complete(UserCreatable *uc, Error **errp)
+{
+ QCryptoTLSCreds *s = QCRYPTO_TLS_CREDS(uc);
+
+ if (!s->priority) {
+ error_setg(errp, "'priority' property is not set");
+ return;
+ }
+ parse_cipher_suites(QCRYPTO_TLS_CIPHER_SUITES(s), s->priority, errp);
+}
+
+static void qcrypto_tls_cipher_suites_finalize(Object *obj)
+{
+ QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
+
+ g_free(s->cipher_list);
+}
+
+static void qcrypto_tls_cipher_suites_class_init(ObjectClass *oc, void *data)
+{
+ UserCreatableClass *ucc = USER_CREATABLE_CLASS(oc);
+
+ ucc->complete = qcrypto_tls_cipher_suites_complete;
+}
+
+static const TypeInfo qcrypto_tls_cipher_suites_info = {
+ .parent = TYPE_QCRYPTO_TLS_CREDS,
+ .name = TYPE_QCRYPTO_TLS_CIPHER_SUITES,
+ .instance_size = sizeof(QCryptoTLSCipherSuites),
+ .instance_finalize = qcrypto_tls_cipher_suites_finalize,
+ .class_size = sizeof(QCryptoTLSCredsClass),
+ .class_init = qcrypto_tls_cipher_suites_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_USER_CREATABLE },
+ { }
+ }
+};
+
+static void qcrypto_tls_cipher_suites_register_types(void)
+{
+ type_register_static(&qcrypto_tls_cipher_suites_info);
+}
+
+type_init(qcrypto_tls_cipher_suites_register_types);
diff --git a/crypto/Makefile.objs b/crypto/Makefile.objs
index c2a371b0b4..1c1b5e21ff 100644
--- a/crypto/Makefile.objs
+++ b/crypto/Makefile.objs
@@ -13,6 +13,7 @@ crypto-obj-y += cipher.o
crypto-obj-$(CONFIG_AF_ALG) += afalg.o
crypto-obj-$(CONFIG_AF_ALG) += cipher-afalg.o
crypto-obj-$(CONFIG_AF_ALG) += hash-afalg.o
+crypto-obj-$(CONFIG_GNUTLS) += tls-cipher-suites.o
crypto-obj-y += tlscreds.o
crypto-obj-y += tlscredsanon.o
crypto-obj-y += tlscredspsk.o
diff --git a/crypto/trace-events b/crypto/trace-events
index 9e594d30e8..798b6067ab 100644
--- a/crypto/trace-events
+++ b/crypto/trace-events
@@ -21,3 +21,8 @@ qcrypto_tls_creds_x509_load_cert_list(void *creds, const char *file) "TLS creds
# tlssession.c
qcrypto_tls_session_new(void *session, void *creds, const char *hostname, const char *authzid, int endpoint) "TLS session new session=%p creds=%p hostname=%s authzid=%s endpoint=%d"
qcrypto_tls_session_check_creds(void *session, const char *status) "TLS session check creds session=%p status=%s"
+
+# tls-cipher-suites.c
+qcrypto_tls_cipher_suite_priority(const char *name) "priority: %s"
+qcrypto_tls_cipher_suite_info(uint8_t data0, uint8_t data1, const char *version, const char *name) "data=[0x%02x,0x%02x] version=%s name=%s"
+qcrypto_tls_cipher_suite_count(unsigned count) "count: %u"
diff --git a/qemu-options.hx b/qemu-options.hx
index 93bde2bbc8..4f519f35fd 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4566,6 +4566,25 @@ SRST
string as described at
https://gnutls.org/manual/html_node/Priority-Strings.html.
+ ``-object tls-cipher-suites,id=id,priority=priority``
+ Creates a TLS cipher suites object, which can be used to control
+ the TLS cipher/protocol algorithms that applications are permitted
+ to use.
+
+ The ``id`` parameter is a unique ID which frontends will use to
+ access the ordered list of permitted TLS cipher suites from the
+ host.
+
+ The ``priority`` parameter allows to override the global default
+ priority used by gnutls. This can be useful if the system
+ administrator needs to use a weaker set of crypto priorities for
+ QEMU without potentially forcing the weakness onto all
+ applications. Or conversely if one wants wants a stronger
+ default for QEMU than for all other applications, they can do
+ this through this parameter. Its format is a gnutls priority
+ string as described at
+ https://gnutls.org/manual/html_node/Priority-Strings.html.
+
``-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
--
2.21.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v9 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
` (3 preceding siblings ...)
2020-06-15 10:34 ` [PATCH v9 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
@ 2020-06-15 10:34 ` Philippe Mathieu-Daudé
4 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-15 10:34 UTC (permalink / raw)
To: qemu-devel, Gerd Hoffmann
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Laszlo Ersek, Paolo Bonzini
Since our format is consumable by the fw_cfg device,
we can implement the FW_CFG_DATA_GENERATOR interface.
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
v9: Fixed typos in qemu-options.hx (lersek)
---
crypto/tls-cipher-suites.c | 19 +++++++++++++++++++
qemu-options.hx | 18 ++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/crypto/tls-cipher-suites.c b/crypto/tls-cipher-suites.c
index f02a041f9a..d6ea0ed190 100644
--- a/crypto/tls-cipher-suites.c
+++ b/crypto/tls-cipher-suites.c
@@ -14,6 +14,7 @@
#include "qemu/error-report.h"
#include "crypto/tlscreds.h"
#include "crypto/tls-cipher-suites.h"
+#include "hw/nvram/fw_cfg.h"
#include "trace.h"
static void parse_cipher_suites(QCryptoTLSCipherSuites *s,
@@ -99,11 +100,28 @@ static void qcrypto_tls_cipher_suites_finalize(Object *obj)
g_free(s->cipher_list);
}
+static const void *qcrypto_tls_cipher_suites_get_data(Object *obj)
+{
+ QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
+
+ return s->cipher_list;
+}
+
+static size_t qcrypto_tls_cipher_suites_get_length(Object *obj)
+{
+ QCryptoTLSCipherSuites *s = QCRYPTO_TLS_CIPHER_SUITES(obj);
+
+ return s->cipher_count * sizeof(IANA_TLS_CIPHER);
+}
+
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_get_data;
+ fwgc->get_length = qcrypto_tls_cipher_suites_get_length;
}
static const TypeInfo qcrypto_tls_cipher_suites_info = {
@@ -115,6 +133,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 4f519f35fd..ce54c7359c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4585,6 +4585,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
--
2.21.3
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
2020-06-15 10:34 ` [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
@ 2020-06-16 15:31 ` Daniel P. Berrangé
2020-06-20 17:52 ` Richard Henderson
2020-06-22 13:54 ` Philippe Mathieu-Daudé
0 siblings, 2 replies; 11+ messages in thread
From: Daniel P. Berrangé @ 2020-06-16 15:31 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Paolo Bonzini, Laszlo Ersek, qemu-devel, Gerd Hoffmann
On Mon, Jun 15, 2020 at 12:34:53PM +0200, Philippe Mathieu-Daudé wrote:
> 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>
> ---
> docs/specs/fw_cfg.txt | 9 ++++++-
> include/hw/nvram/fw_cfg.h | 52 +++++++++++++++++++++++++++++++++++++++
> hw/nvram/fw_cfg.c | 36 +++++++++++++++++++++++++++
> 3 files changed, 96 insertions(+), 1 deletion(-)
>
> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
> index 8f1ebc66fa..bc16daa38a 100644
> --- a/docs/specs/fw_cfg.txt
> +++ b/docs/specs/fw_cfg.txt
> @@ -219,7 +219,7 @@ To check the result, read the "control" field:
>
> = Externally Provided Items =
>
> -As of v2.4, "file" fw_cfg items (i.e., items with selector keys above
> +Since v2.4, "file" fw_cfg items (i.e., items with selector keys above
> FW_CFG_FILE_FIRST, and with a corresponding entry in the fw_cfg file
> directory structure) may be inserted via the QEMU command line, using
> the following syntax:
> @@ -230,6 +230,13 @@ Or
>
> -fw_cfg [name=]<item_name>,string=<string>
>
> +Since v5.1, QEMU allows some objects to generate fw_cfg-specific content,
> +the content is then associated with a "file" item using the 'gen_id' option
> +in the command line, using the following syntax:
> +
> + -object <generator-type>,id=<generated_id>,[generator-specific-options] \
> + -fw_cfg [name=]<item_name>,gen_id=<generated_id>
> +
> See QEMU man page for more documentation.
>
> Using item_name with plain ASCII characters only is recommended.
> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
> index 25d9307018..ca69666847 100644
> --- a/include/hw/nvram/fw_cfg.h
> +++ b/include/hw/nvram/fw_cfg.h
> @@ -9,11 +9,43 @@
> #define TYPE_FW_CFG "fw_cfg"
> #define TYPE_FW_CFG_IO "fw_cfg_io"
> #define TYPE_FW_CFG_MEM "fw_cfg_mem"
> +#define TYPE_FW_CFG_DATA_GENERATOR_INTERFACE "fw_cfg-data-generator"
>
> #define FW_CFG(obj) OBJECT_CHECK(FWCfgState, (obj), TYPE_FW_CFG)
> #define FW_CFG_IO(obj) OBJECT_CHECK(FWCfgIoState, (obj), TYPE_FW_CFG_IO)
> #define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
>
> +#define FW_CFG_DATA_GENERATOR_CLASS(class) \
> + OBJECT_CLASS_CHECK(FWCfgDataGeneratorClass, (class), \
> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
> +#define FW_CFG_DATA_GENERATOR_GET_CLASS(obj) \
> + OBJECT_GET_CLASS(FWCfgDataGeneratorClass, (obj), \
> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
> +
> +typedef struct FWCfgDataGeneratorClass {
> + /*< private >*/
> + InterfaceClass parent_class;
> + /*< public >*/
> +
> + /**
> + * get_data:
> + * @obj: the object implementing this interface
> + *
> + * Returns: pointer to start of the generated item data
> + *
> + * The returned pointer is a QObject weak reference, @obj owns
> + * the reference and may free it at any time in the future.
This description is a bit odd. We're just returning a plain byte
array pointer, not a QObject, nor a reference, not will it be
free'd at any time.
> + */
> + const void *(*get_data)(Object *obj);
> + /**
> + * get_length:
> + * @obj: the object implementing this interface
> + *
> + * Returns: the size of the generated item data in bytes
> + */
> + size_t (*get_length)(Object *obj);
I'd be inclined to have a single method that returns a GByteArray,
instead of separate methods for data & length.
That gives you a sized byte array, with a well define lifetime,
which is what the caller really wants here. ie
/**
* get_data:
* @obj: the object implementing this interface
*
* Returns: reference to a byte array containing the data.
* The caller should release the reference when no longer
* required.
*/
GByteArray *(*get_data)(Object *obj);
> +} FWCfgDataGeneratorClass;
> +
....
> +size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
> + const char *gen_id, Error **errp)
> +{
> + FWCfgDataGeneratorClass *klass;
> + Object *obj;
> + size_t size;
> +
> + obj = object_resolve_path_component(object_get_objects_root(), gen_id);
> + if (!obj) {
> + error_setg(errp, "Cannot find object ID '%s'", gen_id);
> + return 0;
> + }
> + if (!object_dynamic_cast(obj, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)) {
> + error_setg(errp, "Object ID '%s' is not a '%s' subclass",
> + gen_id, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE);
> + return 0;
> + }
> + klass = FW_CFG_DATA_GENERATOR_GET_CLASS(obj);
...then the following:
> + size = klass->get_length(obj);
> + if (size == 0) {
> + error_setg(errp, "Object ID '%s' failed to generate fw_cfg data",
> + gen_id);
> + return 0;
> + }
> + fw_cfg_add_file(s, filename, g_memdup(klass->get_data(obj), (guint)size),
> + size);
Can be replaced with:
g_autoptr(GByteArray) data = klass->get_data(obj);
fw_cfg_add_file(s, filename, g_byte_array_steal(data, NULL),
(guint)g_byte_array_get_size(data));
If there's a real possibility of failure, then an 'Error **errp' should
be added to the 'get_data' method, so this code doesn't have to invent
a error message with no useful info on the real failure.
> +
> + return size;
> +}
> +
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 :|
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v9 4/5] crypto: Add tls-cipher-suites object
2020-06-15 10:34 ` [PATCH v9 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
@ 2020-06-16 16:32 ` Daniel P. Berrangé
0 siblings, 0 replies; 11+ messages in thread
From: Daniel P. Berrangé @ 2020-06-16 16:32 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Paolo Bonzini, Laszlo Ersek, qemu-devel, Gerd Hoffmann
On Mon, Jun 15, 2020 at 12:34:56PM +0200, Philippe Mathieu-Daudé wrote:
> 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 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).
>
> [Description from Daniel P. Berrangé, edited by Laszlo Ersek.]
>
> Example of use to dump the cipher suites:
>
> $ qemu-system-x86_64 -S \
> -object tls-cipher-suites,id=mysuite,priority=@SYSTEM \
> -trace qcrypto\*
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> v9: Replaced 'backends' -> 'frontends' (lersek)
> ---
> include/crypto/tls-cipher-suites.h | 38 +++++++++
> crypto/tls-cipher-suites.c | 127 +++++++++++++++++++++++++++++
> crypto/Makefile.objs | 1 +
> crypto/trace-events | 5 ++
> qemu-options.hx | 19 +++++
> 5 files changed, 190 insertions(+)
> create mode 100644 include/crypto/tls-cipher-suites.h
> create mode 100644 crypto/tls-cipher-suites.c
>
> diff --git a/include/crypto/tls-cipher-suites.h b/include/crypto/tls-cipher-suites.h
> new file mode 100644
> index 0000000000..3848393a20
> --- /dev/null
> +++ b/include/crypto/tls-cipher-suites.h
> @@ -0,0 +1,38 @@
> +/*
> + * QEMU TLS Cipher Suites Registry (RFC8447)
> + *
> + * Copyright (c) 2019 Red Hat, Inc.
> + *
> + * Author: Philippe Mathieu-Daudé <philmd@redhat.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef QCRYPTO_TLSCIPHERSUITES_H
> +#define QCRYPTO_TLSCIPHERSUITES_H
> +
> +#include "qom/object.h"
> +#include "crypto/tlscreds.h"
> +
> +#define TYPE_QCRYPTO_TLS_CIPHER_SUITES "tls-cipher-suites"
> +#define QCRYPTO_TLS_CIPHER_SUITES(obj) \
> + OBJECT_CHECK(QCryptoTLSCipherSuites, (obj), TYPE_QCRYPTO_TLS_CIPHER_SUITES)
> +
> +/*
> + * IANA registered TLS ciphers:
> + * https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> + */
> +typedef struct {
> + uint8_t data[2];
> +} QEMU_PACKED IANA_TLS_CIPHER;
> +
> +typedef struct QCryptoTLSCipherSuites {
> + /* <private> */
> + QCryptoTLSCreds parent_obj;
> +
> + /* <public> */
> + IANA_TLS_CIPHER *cipher_list;
> + unsigned cipher_count;
There's no benefit to storing in a IANA_TLS_CIPHER struct
that I can see. If you use a GByteArray for storing the
data to match my suggestion from the previous patch, then.....
> +} QCryptoTLSCipherSuites;
> +
> +#endif /* QCRYPTO_TLSCIPHERSUITES_H */
> diff --git a/crypto/tls-cipher-suites.c b/crypto/tls-cipher-suites.c
> new file mode 100644
> index 0000000000..f02a041f9a
> --- /dev/null
> +++ b/crypto/tls-cipher-suites.c
> @@ -0,0 +1,127 @@
> +/*
> + * QEMU TLS Cipher Suites
> + *
> + * Copyright (c) 2019 Red Hat, Inc.
> + *
> + * Author: Philippe Mathieu-Daudé <philmd@redhat.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qapi/error.h"
> +#include "qom/object_interfaces.h"
> +#include "qemu/error-report.h"
> +#include "crypto/tlscreds.h"
> +#include "crypto/tls-cipher-suites.h"
> +#include "trace.h"
> +
> +static void parse_cipher_suites(QCryptoTLSCipherSuites *s,
> + const char *priority_name, Error **errp)
> +{
> + int ret;
> + const char *err;
> + gnutls_priority_t pcache;
> + enum { M_ENUMERATE, M_GENERATE, M_DONE } mode;
> +
> + assert(priority_name);
> + trace_qcrypto_tls_cipher_suite_priority(priority_name);
> + ret = gnutls_priority_init(&pcache, priority_name, &err);
> + if (ret < 0) {
> + error_setg(errp, "Syntax error using priority '%s': %s",
> + priority_name, gnutls_strerror(ret));
> + return;
> + }
> +
> + for (mode = M_ENUMERATE; mode < M_DONE; mode++) {
> + size_t i;
....this extra loop is not neccessary....
> +
> + for (i = 0;; i++) {
> + int ret;
> + unsigned idx;
> + const char *name;
> + IANA_TLS_CIPHER cipher;
> + gnutls_protocol_t protocol;
> +
> + ret = gnutls_priority_get_cipher_suite_index(pcache, i, &idx);
> + if (ret == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
> + break;
> + }
> + if (ret == GNUTLS_E_UNKNOWN_CIPHER_SUITE) {
> + continue;
> + }
> +
> + name = gnutls_cipher_suite_info(idx, (unsigned char *)&cipher,
> + NULL, NULL, NULL, &protocol);
> + if (name == NULL) {
> + continue;
> + }
> +
> + if (mode == M_GENERATE) {
> + const char *version;
> +
> + version = gnutls_protocol_get_name(protocol);
> + trace_qcrypto_tls_cipher_suite_info(cipher.data[0],
> + cipher.data[1],
> + version, name);
> + s->cipher_list[s->cipher_count] = cipher;
...you can just call g_byte_array_append() here. GByteArray will
efficiently grow as needed - it won't do O(N) re-allocs.
> + }
> + s->cipher_count++;
> + }
> +
> + if (mode == M_ENUMERATE) {
> + if (s->cipher_count == 0) {
> + break;
> + }
> + s->cipher_list = g_new(IANA_TLS_CIPHER, s->cipher_count);
> + s->cipher_count = 0;
> + }
> + }
> + trace_qcrypto_tls_cipher_suite_count(s->cipher_count);
> + gnutls_priority_deinit(pcache);
> +}
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 :|
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
2020-06-16 15:31 ` Daniel P. Berrangé
@ 2020-06-20 17:52 ` Richard Henderson
2020-06-22 13:54 ` Philippe Mathieu-Daudé
1 sibling, 0 replies; 11+ messages in thread
From: Richard Henderson @ 2020-06-20 17:52 UTC (permalink / raw)
To: Daniel P. Berrangé, Philippe Mathieu-Daudé
Cc: Paolo Bonzini, Laszlo Ersek, qemu-devel, Gerd Hoffmann
On 6/16/20 8:31 AM, Daniel P. Berrangé wrote:
> fw_cfg_add_file(s, filename, g_byte_array_steal(data, NULL),
> (guint)g_byte_array_get_size(data));
FWIW, you can't both read the size and steal the data in the argument list like
this -- the evaluation order is unspecified.
r~
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
2020-06-16 15:31 ` Daniel P. Berrangé
2020-06-20 17:52 ` Richard Henderson
@ 2020-06-22 13:54 ` Philippe Mathieu-Daudé
2020-06-22 14:08 ` Daniel P. Berrangé
1 sibling, 1 reply; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-22 13:54 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Paolo Bonzini, Laszlo Ersek, qemu-devel, Gerd Hoffmann
On 6/16/20 5:31 PM, Daniel P. Berrangé wrote:
> On Mon, Jun 15, 2020 at 12:34:53PM +0200, Philippe Mathieu-Daudé wrote:
>> 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>
>> ---
>> docs/specs/fw_cfg.txt | 9 ++++++-
>> include/hw/nvram/fw_cfg.h | 52 +++++++++++++++++++++++++++++++++++++++
>> hw/nvram/fw_cfg.c | 36 +++++++++++++++++++++++++++
>> 3 files changed, 96 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
>> index 8f1ebc66fa..bc16daa38a 100644
>> --- a/docs/specs/fw_cfg.txt
>> +++ b/docs/specs/fw_cfg.txt
>> @@ -219,7 +219,7 @@ To check the result, read the "control" field:
>>
>> = Externally Provided Items =
>>
>> -As of v2.4, "file" fw_cfg items (i.e., items with selector keys above
>> +Since v2.4, "file" fw_cfg items (i.e., items with selector keys above
>> FW_CFG_FILE_FIRST, and with a corresponding entry in the fw_cfg file
>> directory structure) may be inserted via the QEMU command line, using
>> the following syntax:
>> @@ -230,6 +230,13 @@ Or
>>
>> -fw_cfg [name=]<item_name>,string=<string>
>>
>> +Since v5.1, QEMU allows some objects to generate fw_cfg-specific content,
>> +the content is then associated with a "file" item using the 'gen_id' option
>> +in the command line, using the following syntax:
>> +
>> + -object <generator-type>,id=<generated_id>,[generator-specific-options] \
>> + -fw_cfg [name=]<item_name>,gen_id=<generated_id>
>> +
>> See QEMU man page for more documentation.
>>
>> Using item_name with plain ASCII characters only is recommended.
>> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
>> index 25d9307018..ca69666847 100644
>> --- a/include/hw/nvram/fw_cfg.h
>> +++ b/include/hw/nvram/fw_cfg.h
>> @@ -9,11 +9,43 @@
>> #define TYPE_FW_CFG "fw_cfg"
>> #define TYPE_FW_CFG_IO "fw_cfg_io"
>> #define TYPE_FW_CFG_MEM "fw_cfg_mem"
>> +#define TYPE_FW_CFG_DATA_GENERATOR_INTERFACE "fw_cfg-data-generator"
>>
>> #define FW_CFG(obj) OBJECT_CHECK(FWCfgState, (obj), TYPE_FW_CFG)
>> #define FW_CFG_IO(obj) OBJECT_CHECK(FWCfgIoState, (obj), TYPE_FW_CFG_IO)
>> #define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
>>
>> +#define FW_CFG_DATA_GENERATOR_CLASS(class) \
>> + OBJECT_CLASS_CHECK(FWCfgDataGeneratorClass, (class), \
>> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
>> +#define FW_CFG_DATA_GENERATOR_GET_CLASS(obj) \
>> + OBJECT_GET_CLASS(FWCfgDataGeneratorClass, (obj), \
>> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
>> +
>> +typedef struct FWCfgDataGeneratorClass {
>> + /*< private >*/
>> + InterfaceClass parent_class;
>> + /*< public >*/
>> +
>> + /**
>> + * get_data:
>> + * @obj: the object implementing this interface
>> + *
>> + * Returns: pointer to start of the generated item data
>> + *
>> + * The returned pointer is a QObject weak reference, @obj owns
>> + * the reference and may free it at any time in the future.
>
> This description is a bit odd. We're just returning a plain byte
> array pointer, not a QObject, nor a reference, not will it be
> free'd at any time.
>
>> + */
>> + const void *(*get_data)(Object *obj);
>> + /**
>> + * get_length:
>> + * @obj: the object implementing this interface
>> + *
>> + * Returns: the size of the generated item data in bytes
>> + */
>> + size_t (*get_length)(Object *obj);
>
> I'd be inclined to have a single method that returns a GByteArray,
> instead of separate methods for data & length.
>
> That gives you a sized byte array, with a well define lifetime,
> which is what the caller really wants here. ie
>
> /**
> * get_data:
> * @obj: the object implementing this interface
> *
> * Returns: reference to a byte array containing the data.
> * The caller should release the reference when no longer
> * required.
> */
> GByteArray *(*get_data)(Object *obj);
>
>> +} FWCfgDataGeneratorClass;
>> +
>
> ....
>
>
>> +size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
>> + const char *gen_id, Error **errp)
>> +{
>> + FWCfgDataGeneratorClass *klass;
>> + Object *obj;
>> + size_t size;
>> +
>> + obj = object_resolve_path_component(object_get_objects_root(), gen_id);
>> + if (!obj) {
>> + error_setg(errp, "Cannot find object ID '%s'", gen_id);
>> + return 0;
>> + }
>> + if (!object_dynamic_cast(obj, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)) {
>> + error_setg(errp, "Object ID '%s' is not a '%s' subclass",
>> + gen_id, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE);
>> + return 0;
>> + }
>> + klass = FW_CFG_DATA_GENERATOR_GET_CLASS(obj);
>
> ...then the following:
>
>> + size = klass->get_length(obj);
>> + if (size == 0) {
>> + error_setg(errp, "Object ID '%s' failed to generate fw_cfg data",
>> + gen_id);
>> + return 0;
>> + }
>> + fw_cfg_add_file(s, filename, g_memdup(klass->get_data(obj), (guint)size),
>> + size);
>
> Can be replaced with:
>
> g_autoptr(GByteArray) data = klass->get_data(obj);
>
> fw_cfg_add_file(s, filename, g_byte_array_steal(data, NULL),
> (guint)g_byte_array_get_size(data));
g_byte_array_steal() has been added in GLib 2.64,
QEMU supports up to 2.48.
I guess I have to use g_byte_array_free_to_bytes()
and g_memdup(g_bytes_get_data()) to achieve something
similar. I'll try.
>
>
> If there's a real possibility of failure, then an 'Error **errp' should
> be added to the 'get_data' method, so this code doesn't have to invent
> a error message with no useful info on the real failure.
>
>> +
>> + return size;
>> +}
>> +
>
> Regards,
> Daniel
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface
2020-06-22 13:54 ` Philippe Mathieu-Daudé
@ 2020-06-22 14:08 ` Daniel P. Berrangé
0 siblings, 0 replies; 11+ messages in thread
From: Daniel P. Berrangé @ 2020-06-22 14:08 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Paolo Bonzini, Laszlo Ersek, qemu-devel, Gerd Hoffmann
On Mon, Jun 22, 2020 at 03:54:58PM +0200, Philippe Mathieu-Daudé wrote:
> On 6/16/20 5:31 PM, Daniel P. Berrangé wrote:
> > On Mon, Jun 15, 2020 at 12:34:53PM +0200, Philippe Mathieu-Daudé wrote:
> >> 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>
> >> ---
> >> docs/specs/fw_cfg.txt | 9 ++++++-
> >> include/hw/nvram/fw_cfg.h | 52 +++++++++++++++++++++++++++++++++++++++
> >> hw/nvram/fw_cfg.c | 36 +++++++++++++++++++++++++++
> >> 3 files changed, 96 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
> >> index 8f1ebc66fa..bc16daa38a 100644
> >> --- a/docs/specs/fw_cfg.txt
> >> +++ b/docs/specs/fw_cfg.txt
> >> @@ -219,7 +219,7 @@ To check the result, read the "control" field:
> >>
> >> = Externally Provided Items =
> >>
> >> -As of v2.4, "file" fw_cfg items (i.e., items with selector keys above
> >> +Since v2.4, "file" fw_cfg items (i.e., items with selector keys above
> >> FW_CFG_FILE_FIRST, and with a corresponding entry in the fw_cfg file
> >> directory structure) may be inserted via the QEMU command line, using
> >> the following syntax:
> >> @@ -230,6 +230,13 @@ Or
> >>
> >> -fw_cfg [name=]<item_name>,string=<string>
> >>
> >> +Since v5.1, QEMU allows some objects to generate fw_cfg-specific content,
> >> +the content is then associated with a "file" item using the 'gen_id' option
> >> +in the command line, using the following syntax:
> >> +
> >> + -object <generator-type>,id=<generated_id>,[generator-specific-options] \
> >> + -fw_cfg [name=]<item_name>,gen_id=<generated_id>
> >> +
> >> See QEMU man page for more documentation.
> >>
> >> Using item_name with plain ASCII characters only is recommended.
> >> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
> >> index 25d9307018..ca69666847 100644
> >> --- a/include/hw/nvram/fw_cfg.h
> >> +++ b/include/hw/nvram/fw_cfg.h
> >> @@ -9,11 +9,43 @@
> >> #define TYPE_FW_CFG "fw_cfg"
> >> #define TYPE_FW_CFG_IO "fw_cfg_io"
> >> #define TYPE_FW_CFG_MEM "fw_cfg_mem"
> >> +#define TYPE_FW_CFG_DATA_GENERATOR_INTERFACE "fw_cfg-data-generator"
> >>
> >> #define FW_CFG(obj) OBJECT_CHECK(FWCfgState, (obj), TYPE_FW_CFG)
> >> #define FW_CFG_IO(obj) OBJECT_CHECK(FWCfgIoState, (obj), TYPE_FW_CFG_IO)
> >> #define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
> >>
> >> +#define FW_CFG_DATA_GENERATOR_CLASS(class) \
> >> + OBJECT_CLASS_CHECK(FWCfgDataGeneratorClass, (class), \
> >> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
> >> +#define FW_CFG_DATA_GENERATOR_GET_CLASS(obj) \
> >> + OBJECT_GET_CLASS(FWCfgDataGeneratorClass, (obj), \
> >> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)
> >> +
> >> +typedef struct FWCfgDataGeneratorClass {
> >> + /*< private >*/
> >> + InterfaceClass parent_class;
> >> + /*< public >*/
> >> +
> >> + /**
> >> + * get_data:
> >> + * @obj: the object implementing this interface
> >> + *
> >> + * Returns: pointer to start of the generated item data
> >> + *
> >> + * The returned pointer is a QObject weak reference, @obj owns
> >> + * the reference and may free it at any time in the future.
> >
> > This description is a bit odd. We're just returning a plain byte
> > array pointer, not a QObject, nor a reference, not will it be
> > free'd at any time.
> >
> >> + */
> >> + const void *(*get_data)(Object *obj);
> >> + /**
> >> + * get_length:
> >> + * @obj: the object implementing this interface
> >> + *
> >> + * Returns: the size of the generated item data in bytes
> >> + */
> >> + size_t (*get_length)(Object *obj);
> >
> > I'd be inclined to have a single method that returns a GByteArray,
> > instead of separate methods for data & length.
> >
> > That gives you a sized byte array, with a well define lifetime,
> > which is what the caller really wants here. ie
> >
> > /**
> > * get_data:
> > * @obj: the object implementing this interface
> > *
> > * Returns: reference to a byte array containing the data.
> > * The caller should release the reference when no longer
> > * required.
> > */
> > GByteArray *(*get_data)(Object *obj);
> >
> >> +} FWCfgDataGeneratorClass;
> >> +
> >
> > ....
> >
> >
> >> +size_t fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
> >> + const char *gen_id, Error **errp)
> >> +{
> >> + FWCfgDataGeneratorClass *klass;
> >> + Object *obj;
> >> + size_t size;
> >> +
> >> + obj = object_resolve_path_component(object_get_objects_root(), gen_id);
> >> + if (!obj) {
> >> + error_setg(errp, "Cannot find object ID '%s'", gen_id);
> >> + return 0;
> >> + }
> >> + if (!object_dynamic_cast(obj, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE)) {
> >> + error_setg(errp, "Object ID '%s' is not a '%s' subclass",
> >> + gen_id, TYPE_FW_CFG_DATA_GENERATOR_INTERFACE);
> >> + return 0;
> >> + }
> >> + klass = FW_CFG_DATA_GENERATOR_GET_CLASS(obj);
> >
> > ...then the following:
> >
> >> + size = klass->get_length(obj);
> >> + if (size == 0) {
> >> + error_setg(errp, "Object ID '%s' failed to generate fw_cfg data",
> >> + gen_id);
> >> + return 0;
> >> + }
> >> + fw_cfg_add_file(s, filename, g_memdup(klass->get_data(obj), (guint)size),
> >> + size);
> >
> > Can be replaced with:
> >
> > g_autoptr(GByteArray) data = klass->get_data(obj);
> >
> > fw_cfg_add_file(s, filename, g_byte_array_steal(data, NULL),
> > (guint)g_byte_array_get_size(data));
>
> g_byte_array_steal() has been added in GLib 2.64,
> QEMU supports up to 2.48.
>
> I guess I have to use g_byte_array_free_to_bytes()
> and g_memdup(g_bytes_get_data()) to achieve something
> similar. I'll try.
Or can possibly use the simpler g_byte_array_free and avoid the g_autoptr
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 :|
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-06-22 14:11 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 10:34 [PATCH v9 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-06-16 15:31 ` Daniel P. Berrangé
2020-06-20 17:52 ` Richard Henderson
2020-06-22 13:54 ` Philippe Mathieu-Daudé
2020-06-22 14:08 ` Daniel P. Berrangé
2020-06-15 10:34 ` [PATCH v9 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace Philippe Mathieu-Daudé
2020-06-15 10:34 ` [PATCH v9 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-06-16 16:32 ` Daniel P. Berrangé
2020-06-15 10:34 ` [PATCH v9 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob Philippe Mathieu-Daudé
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.