linux-kernel - Re: WARNING in vcpu_enter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87tv2j2lsc.fsf@nanos.tec.linutronix.de>
Date:   Fri, 20 Mar 2020 14:33:39 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     syzbot <syzbot+00be5da1d75f1cc95f6b@...kaller.appspotmail.com>,
        bp@...en8.de, hpa@...or.com, jmattson@...gle.com, joro@...tes.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        mingo@...hat.com, rkrcmar@...hat.com,
        syzkaller-bugs@...glegroups.com, vkuznets@...hat.com,
        wanpengli@...cent.com, x86@...nel.org
Subject: Re: WARNING in vcpu_enter_guest

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