linux-kernel - Re: [PATCH] KVM: VMX: remove LFENCE in vmx_spec_ctrl_restore

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: <20230605163552.hi5kvh5wijegmus6@treble>
Date:   Mon, 5 Jun 2023 09:35:52 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Jon Kohler <jon@...anix.com>
Cc:     Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
        "kvm @ vger . kernel . org" <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: VMX: remove LFENCE in vmx_spec_ctrl_restore_host()

On Mon, Jun 05, 2023 at 02:29:02PM +0000, Jon Kohler wrote:
> 
> 
> > On Jun 1, 2023, at 12:23 AM, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > 
> > On Wed, May 31, 2023 at 06:24:29PM -0700, Pawan Gupta wrote:
> > 
> > ## 2023-05-31
> >> On Thu, Jun 01, 2023 at 01:50:48AM +0100, Andrew Cooper wrote:
> >>> On 01/06/2023 1:42 am, Josh Poimboeuf wrote:
> >>>> So each LFENCE has a distinct purpose.  That said, there are no indirect
> >>>> branches or unbalanced RETs between them.
> >>> 
> >>> How lucky are you feeling?
> >>> 
> >>> You're in C at this point, which means the compiler could have emitted a
> >>> call to mem{cpy,cmp}() in place of a simple assignment/comparison.
> >> 
> >> Moving the second LFENCE to the else part of WRMSR should be possible?
> >> So that the serialization can be achived either by WRMSR or LFENCE. This
> >> saves an LFENCE when host and guest value of MSR_SPEC_CTRL differ.
> > 
> > Yes.  Though in practice it might not make much of a difference.  With
> > wrmsr+lfence, the lfence has nothing to do so it might be almost
> > instantaneous anyway.
> > 
> > -- 
> > Josh
> 
> Coming back to this, what if we hoisted call vmx_spec_ctrl_restore_host above
> FILL_RETURN_BUFFER, and dropped this LFENCE as I did here?
> 
> That way, we wouldn’t have to mess with the internal LFENCE in nospec-branch.h,
> and that would act as the “final line of defense” LFENCE.
> 
> Would that be acceptable? Or does FILL_RETURN_BUFFER *need* to occur
> before any sort of calls no matter what?

If we go by Intel's statement that only unbalanced RETs are a concern,
that *might* be ok as long as there's a nice comment above the
FILL_RETURN_BUFFER usage site describing the two purposes for the
LFENCE.

However, based on Andy's concerns, which I've discussed with him
privately (but I'm not qualified to agree or disagree with), we may want
to just convert vmx_spec_ctrl_restore_host() to asm.  Better safe than
sorry.  My original implementation of that function was actually asm.  I
can try to dig up that code.

-- 
Josh