linux-kernel - Re: [PATCH] KVM: x86/mmu: Add capability to zap only sptes for the affected memslot

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:   Mon, 13 Jul 2020 12:22:26 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Xiong Zhang <xiong.y.zhang@...el.com>,
        Wayne Boyer <wayne.boyer@...el.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        Jun Nakajima <jun.nakajima@...el.com>
Subject: Re: [PATCH] KVM: x86/mmu: Add capability to zap only sptes for the
 affected memslot

On Thu, 9 Jul 2020 21:29:22 -0700
Sean Christopherson <sean.j.christopherson@...el.com> wrote:

> +Alex, whom I completely spaced on Cc'ing.
> 
> Alex, this is related to the dreaded VFIO memslot zapping issue from last
> year.  Start of thread: https://patchwork.kernel.org/patch/11640719/.
> 
> The TL;DR of below: can you try the attached patch with your reproducer
> from the original bug[*]?  I honestly don't know whether it has a legitimate
> chance of working, but it's the one thing in all of this that I know was
> definitely a bug.  I'd like to test it out if only to sate my curiosity.
> Absolutely no rush.

Mixed results, maybe you can provide some guidance.  Running this
against v5.8-rc4, I haven't reproduced the glitch.  But it's been a
long time since I tested this previously, so I went back to v5.3-rc5 to
make sure I still have a recipe to trigger it.  I can still get the
failure there as the selective flush commit was reverted in rc6.  Then
I wondered, can I take broken v5.3-rc5 and apply this fix to prove that
it works?  No, v5.3-rc5 + this patch still glitches.  So I thought
maybe I could make v5.8-rc4 break by s/true/false/ in this patch.
Nope.  Then I applied the original patch from[1] to try to break it.
Nope.  So if anything, I think the evidence suggests this was broken
elsewhere and is now fixed, or maybe it is a timing issue that I can't
trigger on newer kernels.  If the reproducer wasn't so touchy and time
consuming, I'd try to bisect, but I don't have that sort of bandwidth.
Thanks,

Alex

[1] https://patchwork.kernel.org/patch/10798453/