From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Laszlo Ersek" <lersek@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>
Subject: [PULL 1/1] hw/nvram/fw_cfg: fix FWCfgDataGeneratorClass::get_data() consumption
Date: Fri, 18 Sep 2020 17:22:07 +0200 [thread overview]
Message-ID: <20200918152207.157589-2-philmd@redhat.com> (raw)
In-Reply-To: <20200918152207.157589-1-philmd@redhat.com>
From: Laszlo Ersek <lersek@redhat.com>
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>
---
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 f3a4728288e..0e95d057fd5 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.26.2
next prev parent reply other threads:[~2020-09-18 15:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 15:22 [PULL 0/1] fw-cfg patches for 2020-09-18 Philippe Mathieu-Daudé
2020-09-18 15:22 ` Philippe Mathieu-Daudé [this message]
2020-09-18 15:27 ` no-reply
2020-09-18 16:23 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200918152207.157589-2-philmd@redhat.com \
--to=philmd@redhat.com \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).