linux-kernel - Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

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, 5 Feb 2018 12:10:34 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        David Woodhouse <dwmw2@...radead.org>,
        Jim Mattson <jmattson@...gle.com>,
        Mihai Carabas <mihai.carabas@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kvm list <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Liran Alon <liran.alon@...cle.com>,
        Anthony Liguori <aliguori@...zon.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Borislav Petkov <bp@...en8.de>,
        the arch/x86 maintainers <x86@...nel.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID
 availability


* Paolo Bonzini <pbonzini@...hat.com> wrote:

> On 30/01/2018 12:45, Thomas Gleixner wrote:
> > On Tue, 30 Jan 2018, David Woodhouse wrote:
> > 
> >> On Tue, 2018-01-30 at 08:57 -0800, Jim Mattson wrote:
> >>> It's really hard to tell which patches are being proposed for which
> >>> repositories, but assuming that everything else is correct, I don't
> >>> think your condition is adequate. What if the physical CPU and the
> >>> virtual CPU both have CPUID.(EAX=7H,ECX=0):EDX[26], but only the
> >>> physical CPU has CPUID.(EAX=7H,ECX=0):EDX[27]? If the guest has write
> >>> access to MSR_IA32_SPEC_CTRL, it can set MSR_IA32_SPEC_CTRL[1]
> >>> (STIBP), even though setting that bit in the guest should raise #GP.
> >>
> >> Everything we're talking about here is for tip/x86/pti. Which I note
> >> has just updated to be 4.15-based, although I thought it was going to
> >> stay on 4.14 for now. So I've updated my tree at
> >> http://git.infradead.org/linux-retpoline.git/shortlog/refs/heads/ibpb
> >> accordingly.
> > 
> > Yes, we tried to stay on 4.14 base but this started to created nasty merge
> > conflicts for no value. Merging in v4.15 turned out to resolve those issues
> > while still serving as the feed branch for Gregs stable work. For the time
> > being we try to make stable backporting at least for 4.14/15 as painless as
> > possible.
> 
> Great, then the "per-VCPU MSR bitmaps" branch
> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git refs/heads/msr-bitmaps)
> that I created last weekend can be pulled directly in tip/x86/pti.

Can this branch still be rebased, to fix the SoB chain of:

  de3a0021a606 ("KVM: nVMX: Eliminate vmcs02 pool")

?

I'm not sure what workflow resulted in this commit, but it is missing your SoB:

  commit de3a0021a60635de96aa92713c1a31a96747d72c
  Author:     Jim Mattson <jmattson@...gle.com>
  AuthorDate: Mon Nov 27 17:22:25 2017 -0600
  Commit:     Paolo Bonzini <pbonzini@...hat.com>
  CommitDate: Sat Jan 27 09:43:03 2018 +0100

    KVM: nVMX: Eliminate vmcs02 pool
    
    The potential performance advantages of a vmcs02 pool have never been
    realized. To simplify the code, eliminate the pool. Instead, a single
    vmcs02 is allocated per VCPU when the VCPU enters VMX operation.
    
    Cc: stable@...r.kernel.org       # prereq for Spectre mitigation
    Signed-off-by: Jim Mattson <jmattson@...gle.com>
    Signed-off-by: Mark Kanda <mark.kanda@...cle.com>
    Reviewed-by: Ameya More <ameya.more@...cle.com>
    Reviewed-by: David Hildenbrand <david@...hat.com>
    Reviewed-by: Paolo Bonzini <pbonzini@...hat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@...hat.com>

You probably rebased Radim'm tree?

If this tree can still be rebased I'd like to re-pull it into tip:x86/pti, as
those bits are not yet upstream.

Thanks,

	Ingo