qemu/hw/display/ramfb.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

156 lines
4.0 KiB
C
Raw Normal View History

/*
* early boot framebuffer in guest ram
* configured using fw_cfg
*
* Copyright Red Hat, Inc. 2017
*
* Author:
* Gerd Hoffmann <kraxel@redhat.com>
*
* This work is licensed under the terms of the GNU GPL, version 2 or later.
* See the COPYING file in the top-level directory.
*/
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "hw/loader.h"
#include "hw/display/ramfb.h"
#include "hw/display/bochs-vbe.h" /* for limits */
#include "ui/console.h"
#include "sysemu/reset.h"
struct QEMU_PACKED RAMFBCfg {
uint64_t addr;
uint32_t fourcc;
uint32_t flags;
uint32_t width;
uint32_t height;
uint32_t stride;
};
typedef struct RAMFBCfg RAMFBCfg;
struct RAMFBState {
DisplaySurface *ds;
uint32_t width, height;
struct RAMFBCfg cfg;
};
static void ramfb_unmap_display_surface(pixman_image_t *image, void *unused)
{
void *data = pixman_image_get_data(image);
uint32_t size = pixman_image_get_stride(image) *
pixman_image_get_height(image);
cpu_physical_memory_unmap(data, size, 0, 0);
}
static DisplaySurface *ramfb_create_display_surface(int width, int height,
pixman_format_code_t format,
hwaddr stride, hwaddr addr)
{
DisplaySurface *surface;
hwaddr size, mapsize, linesize;
void *data;
if (width < 16 || width > VBE_DISPI_MAX_XRES ||
height < 16 || height > VBE_DISPI_MAX_YRES ||
format == 0 /* unknown format */)
return NULL;
linesize = width * PIXMAN_FORMAT_BPP(format) / 8;
if (stride == 0) {
stride = linesize;
}
mapsize = size = stride * (height - 1) + linesize;
data = cpu_physical_memory_map(addr, &mapsize, false);
if (size != mapsize) {
cpu_physical_memory_unmap(data, mapsize, 0, 0);
return NULL;
}
surface = qemu_create_displaysurface_from(width, height,
format, stride, data);
pixman_image_set_destroy_function(surface->image,
ramfb_unmap_display_surface, NULL);
return surface;
}
static void ramfb_fw_cfg_write(void *dev, off_t offset, size_t len)
{
RAMFBState *s = dev;
DisplaySurface *surface;
uint32_t fourcc, format, width, height;
hwaddr stride, addr;
width = be32_to_cpu(s->cfg.width);
height = be32_to_cpu(s->cfg.height);
stride = be32_to_cpu(s->cfg.stride);
fourcc = be32_to_cpu(s->cfg.fourcc);
addr = be64_to_cpu(s->cfg.addr);
format = qemu_drm_format_to_pixman(fourcc);
surface = ramfb_create_display_surface(width, height,
format, stride, addr);
if (!surface) {
return;
}
s->width = width;
s->height = height;
hw/display/ramfb: plug slight guest-triggerable leak on mode setting The fw_cfg DMA write callback in ramfb prepares a new display surface in QEMU; this new surface is put to use ("swapped in") upon the next display update. At that time, the old surface (if any) is released. If the guest triggers the fw_cfg DMA write callback at least twice between two adjacent display updates, then the second callback (and further such callbacks) will leak the previously prepared (but not yet swapped in) display surface. The issue can be shown by: (1) starting QEMU with "-trace displaysurface_free", and (2) running the following program in the guest UEFI shell: > #include <Library/ShellCEntryLib.h> // ShellAppMain() > #include <Library/UefiBootServicesTableLib.h> // gBS > #include <Protocol/GraphicsOutput.h> // EFI_GRAPHICS_OUTPUT_PROTOCOL > > INTN > EFIAPI > ShellAppMain ( > IN UINTN Argc, > IN CHAR16 **Argv > ) > { > EFI_STATUS Status; > VOID *Interface; > EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop; > UINT32 Mode; > > Status = gBS->LocateProtocol ( > &gEfiGraphicsOutputProtocolGuid, > NULL, > &Interface > ); > if (EFI_ERROR (Status)) { > return 1; > } > > Gop = Interface; > > Mode = 1; > for ( ; ;) { > Status = Gop->SetMode (Gop, Mode); > if (EFI_ERROR (Status)) { > break; > } > > Mode = 1 - Mode; > } > > return 1; > } The symptom is then that: - only one trace message appears periodically, - the time between adjacent messages keeps increasing -- implying that some list structure (containing the leaked resources) keeps growing, - the "surface" pointer is ever different. > 18566@1695127471.449586:displaysurface_free surface=0x7f2fcc09a7c0 > 18566@1695127471.529559:displaysurface_free surface=0x7f2fcc9dac10 > 18566@1695127471.659812:displaysurface_free surface=0x7f2fcc441dd0 > 18566@1695127471.839669:displaysurface_free surface=0x7f2fcc0363d0 > 18566@1695127472.069674:displaysurface_free surface=0x7f2fcc413a80 > 18566@1695127472.349580:displaysurface_free surface=0x7f2fcc09cd00 > 18566@1695127472.679783:displaysurface_free surface=0x7f2fcc1395f0 > 18566@1695127473.059848:displaysurface_free surface=0x7f2fcc1cae50 > 18566@1695127473.489724:displaysurface_free surface=0x7f2fcc42fc50 > 18566@1695127473.969791:displaysurface_free surface=0x7f2fcc45dcc0 > 18566@1695127474.499708:displaysurface_free surface=0x7f2fcc70b9d0 > 18566@1695127475.079769:displaysurface_free surface=0x7f2fcc82acc0 > 18566@1695127475.709941:displaysurface_free surface=0x7f2fcc369c00 > 18566@1695127476.389619:displaysurface_free surface=0x7f2fcc32b910 > 18566@1695127477.119772:displaysurface_free surface=0x7f2fcc0d5a20 > 18566@1695127477.899517:displaysurface_free surface=0x7f2fcc086c40 > 18566@1695127478.729962:displaysurface_free surface=0x7f2fccc72020 > 18566@1695127479.609839:displaysurface_free surface=0x7f2fcc185160 > 18566@1695127480.539688:displaysurface_free surface=0x7f2fcc23a7e0 > 18566@1695127481.519759:displaysurface_free surface=0x7f2fcc3ec870 > 18566@1695127482.549930:displaysurface_free surface=0x7f2fcc634960 > 18566@1695127483.629661:displaysurface_free surface=0x7f2fcc26b140 > 18566@1695127484.759987:displaysurface_free surface=0x7f2fcc321700 > 18566@1695127485.940289:displaysurface_free surface=0x7f2fccaad100 We figured this wasn't a CVE-worthy problem, as only small amounts of memory were leaked (the framebuffer itself is mapped from guest RAM, QEMU only allocates administrative structures), plus libvirt restricts QEMU memory footprint anyway, thus the guest can only DoS itself. Plug the leak, by releasing the last prepared (not yet swapped in) display surface, if any, in the fw_cfg DMA write callback. Regarding the "reproducer", with the fix in place, the log is flooded with trace messages (one per fw_cfg write), *and* the trace message alternates between just two "surface" pointer values (i.e., nothing is leaked, the allocator flip-flops between two objects in effect). This issue appears to date back to the introducion of ramfb (995b30179bdc, "hw/display: add ramfb, a simple boot framebuffer living in guest ram", 2018-06-18). Cc: Gerd Hoffmann <kraxel@redhat.com> (maintainer:ramfb) Cc: qemu-stable@nongnu.org Fixes: 995b30179bdc Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230919131955.27223-1-lersek@redhat.com>
2023-09-19 16:19:55 +03:00
qemu_free_displaysurface(s->ds);
s->ds = surface;
}
void ramfb_display_update(QemuConsole *con, RAMFBState *s)
{
if (!s->width || !s->height) {
return;
}
if (s->ds) {
dpy_gfx_replace_surface(con, s->ds);
s->ds = NULL;
}
/* simple full screen update */
dpy_gfx_update_full(con);
}
static int ramfb_post_load(void *opaque, int version_id)
{
ramfb_fw_cfg_write(opaque, 0, 0);
return 0;
}
const VMStateDescription ramfb_vmstate = {
.name = "ramfb",
.version_id = 1,
.minimum_version_id = 1,
.post_load = ramfb_post_load,
.fields = (const VMStateField[]) {
VMSTATE_BUFFER_UNSAFE(cfg, RAMFBState, 0, sizeof(RAMFBCfg)),
VMSTATE_END_OF_LIST()
}
};
RAMFBState *ramfb_setup(Error **errp)
{
FWCfgState *fw_cfg = fw_cfg_find();
RAMFBState *s;
if (!fw_cfg || !fw_cfg->dma_enabled) {
error_setg(errp, "ramfb device requires fw_cfg with DMA");
return NULL;
}
s = g_new0(RAMFBState, 1);
rom_add_vga("vgabios-ramfb.bin");
fw_cfg_add_file_callback(fw_cfg, "etc/ramfb",
NULL, ramfb_fw_cfg_write, s,
&s->cfg, sizeof(s->cfg), false);
return s;
}