linux-kernel - Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC

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: <87v9d9i9dt.fsf@nanos.tec.linutronix.de>
Date:   Thu, 10 Dec 2020 23:28:14 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Maxim Levitsky <mlevitsk@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        kvm list <kvm@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>,
        Jim Mattson <jmattson@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        "open list\:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        open list <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "maintainer\:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" <x86@...nel.org>,
        Joerg Roedel <joro@...tes.org>, Borislav Petkov <bp@...en8.de>,
        Shuah Khan <shuah@...nel.org>,
        Andrew Jones <drjones@...hat.com>,
        Oliver Upton <oupton@...gle.com>,
        "open list\:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC_STATE

On Thu, Dec 10 2020 at 14:01, Andy Lutomirski wrote:
> On Thu, Dec 10, 2020 at 1:25 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>> I'm still convinced that a notification about 'we take a nap' will be
>> more robust, less complex and more trivial to backport.
>
> What do you have in mind?  Suppose the host kernel sends the guest an
> interrupt on all vCPUs saying "I'm about to take a nap".  What happens
> if the guest is busy with IRQs off for a little bit?  Does the host
> guarantee the guest a certain about of time to try to get the
> interrupt delivered before allowing the host to enter S3?  How about
> if the host wants to reboot for a security fix -- how long is a guest
> allowed to delay the process?
>
> I'm sure this can all be made to work 99% of time, but I'm a bit
> concerned about that last 1%.

Seriously?

If the guest has interrupts disabled for ages, i.e. it went for out for
lunch on its own, then surely the hypervisor can just pull the plug and
wreckage it. It's like you hit the reset button or pull the powerplug of
the machine which is not responding anymore.

Reboot waits already today for guests to shut down/hibernate/supsend or
whatever they are supposed to do. systemd sits there and waits for
minutes until it decides to kill them. Just crash a guest kernel and
forget to reset or force power off the guest before you reboot the
host. Twiddle thumbs for a while and watch the incomprehensible time
display.

If your security fix reboot is so urgent that it can't wait then just
pull the plug and be done with it, i.e. kill the guest which makes it
start from a known state which is a gazillion times better than bringing
it into a state which it can't handle anymore.

Again, that's not any different than hitting the reset button on the
host or pulling and reinserting the host powerplug which you would do
anyway in an emergency case.

Can we please focus on real problems instead of making up new ones?

Correctness of time is a real problem despite the believe of virt folks
that it can be ignored or duct taped to death.

Thanks,

        tglx