| Message ID | 20200916151510.22767-1-lersek@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption | expand |
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; > } >
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
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.
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; }