On Mon, 12 Aug 2019 16:38:05 +0100 Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Mon, 12 Aug 2019 at 16:35, Alex Williamson > <alex.william...@redhat.com> wrote: > > Quoting new commit log: > > > > This makes sure the pci config space allocation is big enough, > > so accessing the PCIe extended config space doesn't overflow > > the pci config space buffer. > > > > PCI(e) config space is guest writable. Writes are limited > > bywrite mask (which probably is also filled with random stuff), > > so the guest can only flip enabled bits. But I suspect it > > still might be exploitable, so rather serious because it might > > be a host escape for the guest. On the other hand the device > > is probably not yet in widespread use. > > > > Mitigation: use "-device bochs-display" as conventional pci > > device only. > > > > Is it clear to others that this mitigation remark seems to be > > referencing an alternative configuration constraint to avoid the issue > > rather than what's actually implemented in this patch? IOW, if we > > never place the bochs-display device into a PCIe hierarchy, then > > extended config space is never accessible to the guest anyway, and > > there is no issue. I think this was meant to be an alternative to the > > patch but the enforcement of that would happen above QEMU, probably why > > it was mentioned in the cover letter rather than the original commit > > log. Thanks, > > Yeah, that's unclear in retrospect. How about: > > # (For a QEMU version without this commit, a mitigation for the > # bug is available: use "-device bochs-display" as a conventional pci > # device only.) Yes, better. Thanks, Alex