linux-kernel - Re: [RFC patch 00/15] entry: Provide generic implementation for host and guest entry/exit work

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:   Tue, 24 Sep 2019 08:50:20 +0200
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     x86@...nel.org, Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Marc Zyngier <maz@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-s390 <linux-s390@...r.kernel.org>
Subject: Re: [RFC patch 00/15] entry: Provide generic implementation for host
 and guest entry/exit work

On 19.09.19 17:03, Thomas Gleixner wrote:
> When working on a way to move out the posix cpu timer expiry out of the
> timer interrupt context, I noticed that KVM is not handling pending task
> work before entering a guest. A quick hack was to add that to the x86 KVM
> handling loop. The discussion ended with a request to make this a generic
> infrastructure possible with also moving the per arch implementations of
> the enter from and return to user space handling generic.
> 
>   https://lore.kernel.org/r/89E42BCC-47A8-458B-B06A-D6A20D20512C@amacapital.net
> 
> You asked for it, so don't complain that you have to review it :)
> 
> The series implements the syscall enter/exit and the general exit to
> userspace work handling along with the pre guest enter functionality.
> 
> The series converts x86 and ARM64. x86 is fully tested including selftests
> etc. ARM64 is only compile tested for now as my only ARM64 testbox is not
> available right now.

It seems that s390x would also need to look into TIF_NOTIFY_PENDING before
entering a KVM guest. Given that the s390x entry path is still in assembler
this might not be something to do quickly.

Would it make sense to actually start with a minimal solution (e.g. one that
provides notify_resume_pending like your original patch) as a fix. That would
also be simple to backport. And then we can do the proper rework on top.

Or do we consider anything that depends on TIF_NOTIFY_PENDING before entering
a guest as not important enough for stable?
After all the vcpu_run ioctl almost never returns to userspace and nothing 
was obviously broken.

Another question: Are there callbacks due to TIF_NOTIFY_PENDING that should
NOT happen as long as we stay in the vpcu loop?