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: <alpine.DEB.2.20.1801301842310.1797@nanos>
Date:   Tue, 30 Jan 2018 18:45:19 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     David Woodhouse <dwmw2@...radead.org>
cc:     Jim Mattson <jmattson@...gle.com>,
        Mihai Carabas <mihai.carabas@...cle.com>,
        Paolo Bonzini <pbonzini@...hat.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

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.

Thanks,

	tglx


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ