diff mbox series

hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption

Message ID 20200916151510.22767-1-lersek@redhat.com
State New
Headers show
Series hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption | expand

Commit Message

Laszlo Ersek Sept. 16, 2020, 3:15 p.m. UTC
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(-)

Comments

Philippe Mathieu-Daudé Sept. 16, 2020, 3:57 p.m. UTC | #1
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;

>  }

>
Daniel P. Berrangé Sept. 16, 2020, 4:30 p.m. UTC | #2
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 :|
Philippe Mathieu-Daudé Sept. 18, 2020, 8:34 a.m. UTC | #3
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 mbox series

Patch

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;
 }