lkml.org 
[lkml]   [2020]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: WARNING in vcpu_enter_guest
Date
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 20/03/20 01:18, Thomas Gleixner wrote:
>>> No, it is possible to do that depending on the clock setup on the live
>>> migration source. You could cause the warning anyway by setting the
>>> clock to a very high (signed) value so that kernel_ns + kvmclock_offset
>>> overflows.
>>
>> If that overflow happens, then the original and the new host have an
>> uptime difference in the range of >200 hundreds of years. Very realistic
>> scenario...
>>
>> Of course this can happen if you feed crap into the interface, but do
>> you really think that forwarding all crap to a guest is the right thing
>> to do?
>>
>> As we all know the hypervisor orchestration stuff is perfect and would
>> never feed crap into the kernel which happily proliferates that crap to
>> the guest...
>
> But the point is, is there a sensible way to detect it? Only allowing
> >= -2^62 and < 2^62 or something like that is an ad hoc fix for a
> warning that probably will never trigger outside fuzzing. I would
> expect that passing the wrong sign is a more likely mistake than being
> off by 2^63.
>
> This data is available everywhere between strace, kernel tracepoints and
> QEMU tracepoints or guest checkpoint (live migration) data. I just
> don't see much advantage in keeping the warning.

The warning is useless. But you want a sanity check in the ioctl and
return -EMORON if it is out of bounds simply because the guest will
malfunction if your offset is bogus. Look at the timekeeping and time
namespace sanity checks.

Thanks,

tglx



\
 
 \ /
  Last update: 2020-03-20 14:35    [W:1.437 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site