Re: [PATCH] hw/nvram/fw_cfg: Assert linked data is not NULL

[Laszlo Ersek]

Hi Phil,

On 09/16/20 16:05, Philippe Mathieu-Daudé wrote:
> The linked data passed to the fw_cfg device must not be NULL.
> Add an assertion.
>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  hw/nvram/fw_cfg.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index f3a4728288e..40dcc08b57b 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -711,6 +711,7 @@ static void fw_cfg_add_bytes_callback(FWCfgState *s, 
> uint16_t key,
>
>      key &= FW_CFG_ENTRY_MASK;
>
> +    assert(data);
>      assert(key < fw_cfg_max_entry(s) && len < UINT32_MAX);
>      assert(s->entries[arch][key].data == NULL); /* avoid key conflict */
>
>

(1) this assert() would fire without my

  [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption

so minimally we should apply your patch only after mine.

(2) I'm unsure if it's *always* a programming error to link a NULL datum
under an fw_cfg key. The reader functions fw_cfg_data_read() and
fw_cfg_dma_transfer() deal with NULL data gracefully.

I think we should add the assert() only if we can prove that
"include/hw/nvram/fw_cfg.h" already forbids callers from passing in NULL
data. Otherwise, we'll have to audit all the fw-cfg-add-xxx call sites,
extend the comments in the header file, and *then* add the assert().

For now I'd only go with the patch I posted.

Thanks!
Laszlo