[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] hw/nvram/fw_cfg: Assert linked data is not NULL
From: |
Laszlo Ersek |
Subject: |
Re: [PATCH] hw/nvram/fw_cfg: Assert linked data is not NULL |
Date: |
Wed, 16 Sep 2020 18:16:56 +0200 |
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