Re: [Qemu-devel] qmp: dump-guest-memory: -p option has issues, fix it or drop it?

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> Markus Armbruster <address@hidden> writes:
>
>> Anthony Liguori <address@hidden> writes:
>>
>>> Markus Armbruster <address@hidden> writes:
>>>
>>>> Jan Kiszka <address@hidden> 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.

[...]