On 15/11/2017 14:30, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>> On 15/11/2017 13:51, Daniel P. Berrange wrote:
>>> If you're concerned that someone is tampering with QEMU state
>>> in transit during migration, then you're going to end up playing
>>> whack-a-mole across the entire QEMU codebase IMHO. The answer
>>> to the problem of tampering is to have encryption of the
>>> migration data stream between both QEMU's. Thus QEMU on the
>>> target merely has to trust QEMU on the source. If QEMU on the
>>> source is itself compromised you've already lost and migration
>>> won't make life any worse.
>>
>> This is not entirely true. A lot of such cases were fixed in the past,
>> especially when they could cause out-of-bounds access. Someone could
>> provide a bad migration stream (e.g. as a fake bug report!), so
>> migration data should not be considered trusted.
>
> There's probably others to be honest; it's not something we've
> traditionally been careful of.
There was a flurry of fixes a while ago:
- CVE-2013-4149 to CVE-2013-4151
- CVE-2013-4526 to CVE-2013-4527
- CVE-2013-4529 to CVE-2013-4542
- CVE-2013-6399
- CVE-2014-0182
This one was introduced in 2.1, around the same time these others were
fixed, by commit 2858ab09e6 ("ps2: set ps/2 output buffer size as the
same as kernel", 2014-05-16).
Thanks,
Paolo
>
>> However, PJP's patch breaks migration by changing a 4-byte field to
>> 1-byte. The correct fix is to range-check the fields in
>> ps2_common_post_load.
>
> Agreed.
>
> Dave
>
>> Thanks,
>>
>> Paolo
>>
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
