Anthony Liguori <anth...@codemonkey.ws> writes: > Markus Armbruster <arm...@redhat.com> writes: > >> Anthony Liguori <anth...@codemonkey.ws> writes: >> >>> Markus Armbruster <arm...@redhat.com> writes: >>> >>>> Jan Kiszka <jan.kis...@siemens.com> writes: >>>> >>>>>>>>> * The issues discussed in this email plus the fact that the guest >>>>>>>>> memory may be corrupted, and the guest may be in real-mode even >>>>>>>>> when paging is enabled >>>>>>>>> >>>>>>>> >>>>>>>> Yes, there are some limitations with this option. Jan said that he >>>>>>>> always use gdb to deal with vmcore, so he needs such information. >>>>>>> >>>>>>> The point is to overcome the focus on Linux-only dump processing tools. >>>>>> >>>>>> While I don't care for supporting alternate dump processing tools >>>>>> myself, I certainly don't mind supporting them, as long as the code >>>>>> satisfies basic safety and reliability requirements. >>>>>> >>>>>> This code doesn't, as far as I can tell. >>>>> >>>>> It works, thought not under all circumstances. >>>> >>>> I don't doubt it works often enough to be useful to somebody. But basic >>>> safety and reliability requirements are a bit more than that. They >>>> include "don't explode in ways a reasonable user can't be expected to >>>> foresee". I don't think a reasonable user can be expected to see that >>>> -p is safe only for trusted guests. >>> >>> We shipped the API, we're not removing it. Our compatibility isn't >>> "whatever libvirt is currently using". >> >> Bah, don't be more catholic than the pope. It's been out for how many >> days? Have you looked at the code? >> >>> It's perfectly reasonable to ask to document the behavior of the >>> method. It's also a trivial patch to qapi-schema.json. >> >> I'm okay with leaving obscure security holes in upstream QEMU, >> indefinitely, as long as they're documented. I don't think it's a good >> idea, but it's something reasonable people can disagree about. > > It's *not* a security hole.
Since we agree that documenting the existing crappy behavior is okay for stable, let's not argue what exactly to call it. > The "malicious guest" you mention is just a guest with fully populated > PTEs and PDEs, no? A "normal" guest uses a small fraction of its RAM for page tables. QEMU allocates 10x of that fraction for dump -p. Not so nice. A not-so-normal guest uses most of its RAM for page tables. QEMU allocates in the order of 10x of the guest RAM for -p. Oops. [...]