linux-kernel - Re: [FYI PATCH 0/5] Missing TLB flushes

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] [day] [month] [year] [list]

Message-ID: <CANRm+CyyuWUOAj81Sg8UH_jMybZWmvZxWPWZ_twMvFnPxKD3hQ@mail.gmail.com>
Date:   Sat, 1 Feb 2020 13:53:31 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, kvm <kvm@...r.kernel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [FYI PATCH 0/5] Missing TLB flushes

On Fri, 31 Jan 2020 at 02:02, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
>
> The KVM hypervisor may provide a guest with ability to defer remote TLB
> flush when the remote VCPU is not running. When this feature is used,
> the TLB flush will happen only when the remote VPCU is scheduled to run
> again. This will avoid unnecessary (and expensive) IPIs.
>
> Under certain circumstances, when a guest initiates such deferred action,
> the hypervisor may miss the request. It is also possible that the guest
> may mistakenly assume that it has already marked remote VCPU as needing
> a flush when in fact that request had already been processed by the
> hypervisor. In both cases this will result in an invalid translation
> being present in a vCPU, potentially allowing accesses to memory locations
> in that guest's address space that should not be accessible.
>
> Note that only intra-guest memory is vulnerable.
>
> The attached patches address both of these problems:
> 1. The first patch makes sure the hypervisor doesn't accidentally clear
> guest's remote flush request
> 2. The rest of the patches prevent the race between hypervisor
> acknowledging a remote flush request and guest issuing a new one.

Looks good, thanks for the patchset.

    Wanpeng