Paolo Bonzini <pbonzini@xxxxxxxxxx> 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
