* [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
@ 2020-09-16 15:15 Laszlo Ersek
2020-09-16 15:57 ` Philippe Mathieu-Daudé
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Laszlo Ersek @ 2020-09-16 15:15 UTC (permalink / raw)
To: qemu-devel
Cc: Philippe Mathieu-Daudé, Daniel P. Berrangé,
Gerd Hoffmann
The documentation on g_byte_array_free()
<https://developer.gnome.org/glib/stable/glib-Byte-Arrays.html#g-byte-array-free>
says:
> Returns
>
> the element data if free_segment is FALSE, otherwise NULL. The element
> data should be freed using g_free().
Because we currently call g_byte_array_free() with free_segment=TRUE, we
end up passing data=NULL to fw_cfg_add_file().
On the plus side, fw_cfg_data_read() and fw_cfg_dma_transfer() both deal
with NULL data gracefully: QEMU does not crash when the guest reads such
an item, the guest just gets a properly sized, but zero-filled blob.
However, the bug breaks UEFI HTTPS boot, as the IANA_TLS_CIPHER array,
generated otherwise correctly by the "tls-cipher-suites" object, is in
effect replaced with a zero blob.
Fix the issue by passing free_segment=FALSE to g_byte_array_free():
- the caller (fw_cfg_add_from_generator()) temporarily assumes ownership
of the generated byte array,
- then ownership of the byte array is transfered to fw_cfg, as
fw_cfg_add_file() links (not copies) "data" into fw_cfg.
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Fixes: 3203148917d035b09f71986ac2eaa19a352d6d9d
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
hw/nvram/fw_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index f3a4728288eb..0e95d057fd51 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -1056,7 +1056,7 @@ bool fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
return false;
}
size = array->len;
- fw_cfg_add_file(s, filename, g_byte_array_free(array, TRUE), size);
+ fw_cfg_add_file(s, filename, g_byte_array_free(array, FALSE), size);
return true;
}
--
2.19.1.3.g30247aa5d201
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
2020-09-16 15:15 [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption Laszlo Ersek
@ 2020-09-16 15:57 ` Philippe Mathieu-Daudé
2020-09-16 16:30 ` Daniel P. Berrangé
2020-09-18 8:34 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 4+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-09-16 15:57 UTC (permalink / raw)
To: Laszlo Ersek, qemu-devel; +Cc: Daniel P. Berrangé, Gerd Hoffmann
On 9/16/20 5:15 PM, Laszlo Ersek wrote:
> The documentation on g_byte_array_free()
> <https://developer.gnome.org/glib/stable/glib-Byte-Arrays.html#g-byte-array-free>
> says:
>
>> Returns
>>
>> the element data if free_segment is FALSE, otherwise NULL. The element
>> data should be freed using g_free().
>
> Because we currently call g_byte_array_free() with free_segment=TRUE, we
> end up passing data=NULL to fw_cfg_add_file().
Mea culpa...
>
> On the plus side, fw_cfg_data_read() and fw_cfg_dma_transfer() both deal
> with NULL data gracefully: QEMU does not crash when the guest reads such
> an item, the guest just gets a properly sized, but zero-filled blob.
>
> However, the bug breaks UEFI HTTPS boot, as the IANA_TLS_CIPHER array,
> generated otherwise correctly by the "tls-cipher-suites" object, is in
> effect replaced with a zero blob.
>
> Fix the issue by passing free_segment=FALSE to g_byte_array_free():
>
> - the caller (fw_cfg_add_from_generator()) temporarily assumes ownership
> of the generated byte array,
>
> - then ownership of the byte array is transfered to fw_cfg, as
> fw_cfg_add_file() links (not copies) "data" into fw_cfg.
Thanks!
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Fixes: 3203148917d035b09f71986ac2eaa19a352d6d9d
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> hw/nvram/fw_cfg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index f3a4728288eb..0e95d057fd51 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -1056,7 +1056,7 @@ bool fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
> return false;
> }
> size = array->len;
> - fw_cfg_add_file(s, filename, g_byte_array_free(array, TRUE), size);
> + fw_cfg_add_file(s, filename, g_byte_array_free(array, FALSE), size);
>
> return true;
> }
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
2020-09-16 15:15 [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption Laszlo Ersek
2020-09-16 15:57 ` Philippe Mathieu-Daudé
@ 2020-09-16 16:30 ` Daniel P. Berrangé
2020-09-18 8:34 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 4+ messages in thread
From: Daniel P. Berrangé @ 2020-09-16 16:30 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: Philippe Mathieu-Daudé, qemu-devel, Gerd Hoffmann
On Wed, Sep 16, 2020 at 05:15:10PM +0200, Laszlo Ersek wrote:
> The documentation on g_byte_array_free()
> <https://developer.gnome.org/glib/stable/glib-Byte-Arrays.html#g-byte-array-free>
> says:
>
> > Returns
> >
> > the element data if free_segment is FALSE, otherwise NULL. The element
> > data should be freed using g_free().
>
> Because we currently call g_byte_array_free() with free_segment=TRUE, we
> end up passing data=NULL to fw_cfg_add_file().
>
> On the plus side, fw_cfg_data_read() and fw_cfg_dma_transfer() both deal
> with NULL data gracefully: QEMU does not crash when the guest reads such
> an item, the guest just gets a properly sized, but zero-filled blob.
>
> However, the bug breaks UEFI HTTPS boot, as the IANA_TLS_CIPHER array,
> generated otherwise correctly by the "tls-cipher-suites" object, is in
> effect replaced with a zero blob.
>
> Fix the issue by passing free_segment=FALSE to g_byte_array_free():
>
> - the caller (fw_cfg_add_from_generator()) temporarily assumes ownership
> of the generated byte array,
>
> - then ownership of the byte array is transfered to fw_cfg, as
> fw_cfg_add_file() links (not copies) "data" into fw_cfg.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Fixes: 3203148917d035b09f71986ac2eaa19a352d6d9d
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> hw/nvram/fw_cfg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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] 4+ messages in thread
* Re: [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
2020-09-16 15:15 [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption Laszlo Ersek
2020-09-16 15:57 ` Philippe Mathieu-Daudé
2020-09-16 16:30 ` Daniel P. Berrangé
@ 2020-09-18 8:34 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 4+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-09-18 8:34 UTC (permalink / raw)
To: Laszlo Ersek, qemu-devel; +Cc: Daniel P. Berrangé, Gerd Hoffmann
On 9/16/20 5:15 PM, Laszlo Ersek wrote:
> The documentation on g_byte_array_free()
> <https://developer.gnome.org/glib/stable/glib-Byte-Arrays.html#g-byte-array-free>
> says:
>
>> Returns
>>
>> the element data if free_segment is FALSE, otherwise NULL. The element
>> data should be freed using g_free().
>
> Because we currently call g_byte_array_free() with free_segment=TRUE, we
> end up passing data=NULL to fw_cfg_add_file().
>
> On the plus side, fw_cfg_data_read() and fw_cfg_dma_transfer() both deal
> with NULL data gracefully: QEMU does not crash when the guest reads such
> an item, the guest just gets a properly sized, but zero-filled blob.
>
> However, the bug breaks UEFI HTTPS boot, as the IANA_TLS_CIPHER array,
> generated otherwise correctly by the "tls-cipher-suites" object, is in
> effect replaced with a zero blob.
>
> Fix the issue by passing free_segment=FALSE to g_byte_array_free():
>
> - the caller (fw_cfg_add_from_generator()) temporarily assumes ownership
> of the generated byte array,
>
> - then ownership of the byte array is transfered to fw_cfg, as
> fw_cfg_add_file() links (not copies) "data" into fw_cfg.
>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Fixes: 3203148917d035b09f71986ac2eaa19a352d6d9d
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> hw/nvram/fw_cfg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index f3a4728288eb..0e95d057fd51 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -1056,7 +1056,7 @@ bool fw_cfg_add_from_generator(FWCfgState *s, const char *filename,
> return false;
> }
> size = array->len;
> - fw_cfg_add_file(s, filename, g_byte_array_free(array, TRUE), size);
> + fw_cfg_add_file(s, filename, g_byte_array_free(array, FALSE), size);
>
> return true;
> }
>
Thanks, applied to my fw_cfg tree.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-18 8:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-16 15:15 [PATCH] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption Laszlo Ersek
2020-09-16 15:57 ` Philippe Mathieu-Daudé
2020-09-16 16:30 ` Daniel P. Berrangé
2020-09-18 8:34 ` Philippe Mathieu-Daudé
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).