[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 431843: hw/nvram/fw_cfg: fix FWCfgDataGenerat
From: |
Peter Maydell |
Subject: |
[Qemu-commits] [qemu/qemu] 431843: hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_... |
Date: |
Fri, 18 Sep 2020 09:30:32 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 4318432ccd3f7fb69b7169f39dcae3d4ee04f5ea
https://github.com/qemu/qemu/commit/4318432ccd3f7fb69b7169f39dcae3d4ee04f5ea
Author: Laszlo Ersek <lersek@redhat.com>
Date: 2020-09-18 (Fri, 18 Sep 2020)
Changed paths:
M hw/nvram/fw_cfg.c
Log Message:
-----------
hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
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>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200916151510.22767-1-lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Commit: 053a4177817db307ec854356e95b5b350800a216
https://github.com/qemu/qemu/commit/053a4177817db307ec854356e95b5b350800a216
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2020-09-18 (Fri, 18 Sep 2020)
Changed paths:
M hw/nvram/fw_cfg.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/fw_cfg-20200918'
into staging
fw_cfg patches
Fixes a bug in the recently introduced fw_cfg_add_from_generator().
CI jobs results:
. https://gitlab.com/philmd/qemu/-/pipelines/191714875
. https://travis-ci.org/github/philmd/qemu/builds/728288784
. https://app.shippable.com/github/philmd/qemu/runs/869/1/console
# gpg: Signature made Fri 18 Sep 2020 16:20:56 BST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>"
[full]
# Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* remotes/philmd-gitlab/tags/fw_cfg-20200918:
hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/e883b492c221...053a4177817d
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 431843: hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_...,
Peter Maydell <=