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]

Date:   Fri, 20 Mar 2020 11:33:22 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        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

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.

Paolo