[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v7 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interf
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH v7 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface |
Date: |
Fri, 29 May 2020 11:21:04 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
On 5/29/20 11:09 AM, Laszlo Ersek wrote:
> On 05/28/20 19:31, Philippe Mathieu-Daudé wrote:
>> The FW_CFG_DATA_GENERATOR allows any object to produce
>> blob of data consumable by the fw_cfg device.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>> v7: addressed Laszlo's comments
>> - fixed typos in description
>> - return size_t instead of ssize_t; 0 for error
>> - do not use 1-letter variable names
>> - do not open-code 'fw_cfg-data-generator'
>> - cast g_memdup() size argument as 'guint'
>> - improved documentation
>> ---
>> docs/specs/fw_cfg.txt | 9 ++++++-
>> include/hw/nvram/fw_cfg.h | 52 +++++++++++++++++++++++++++++++++++++++
>> hw/nvram/fw_cfg.c | 31 +++++++++++++++++++++++
>> 3 files changed, 91 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.
>
> I've looked at this hunk with a larger context, and I think it's really
> good.
>
>> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
>> index 25d9307018..8fbf2446c1 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
>
> (1) typo: "object/" (possibly a copy-paste error from my v6 review)
>
>> + * 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 device tree image on success, or 0 on errors.
>
> (2) typo (probably another copy-paste error):
>
> s/device tree image/generated item data/
>
>> + */
>> +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..6d2fa13042 100644
>> --- a/hw/nvram/fw_cfg.c
>> +++ b/hw/nvram/fw_cfg.c
>> @@ -1032,6 +1032,31 @@ 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 '%s' is not a '%s' subclass",
>> + TYPE_FW_CFG_DATA_GENERATOR_INTERFACE, gen_id);
>
> (3) the order of the last two arguments is wrong; please reverse it.
Oops...
>
>> + return 0;
>> + }
>> + klass = FW_CFG_DATA_GENERATOR_GET_CLASS(obj);
>> + size = klass->get_length(obj);
>
> (4) I think we should not call fw_cfg_add_file() if get_length() returns
> zero.
>
> AFAICS, fw_cfg_add_file() will happily create a useless zero-size fw_cfg
> entry, but then the same zero size that we return from
> fw_cfg_add_from_generator() will indicate failure to the caller (and we
> will also not have set "errp").
Good catch.
>
> I think we need something like:
>
> if (size == 0) {
> error_setg(errp, "Object '%s' failed to generate fw_cfg data",
> gen_id);
> return 0;
> }
>
> That will also prevent an awkward call to g_memdup() with size==0.
>
>
> Now, looking at patches #4 and #5, I think if no suitable cipher suite
> is found, then qcrypto_tls_cipher_suites_get_data() will return NULL,
> and qcrypto_tls_cipher_suites_get_length() will return zero. In turn, my
> suggestion (4) here will prevent QEMU from starting up.
>
> And I think that is just fine. The corresponding firmware function is
> SetCipherSuites() in
> "OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.c", and if it sees a
> zero-sized "etc/edk2/https/ciphers" fw_cfg file, it will hang the
> firmware, *on purpose*. (See the reason explained in comments there.)
>
> Thus, it's much better if we prevent QEMU from starting up in the first
> place.
>
>> + 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 +1358,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)
>>
>
> With (1) through (4) fixed:
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Will fix, thanks!
>
> Thanks
> Laszlo
>