linux-kernel - Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

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: <1457738994.2804.266.camel@linuxfoundation.org>
Date:	Fri, 11 Mar 2016 23:29:54 +0000
From:	Richard Purdie <richard.purdie@...uxfoundation.org>
To:	Bruce Ashfield <bruce.ashfield@...driver.com>,
	Borislav Petkov <bp@...e.de>,
	Paolo Bonzini <pbonzini@...hat.com>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Toshi Kani <toshi.kani@....com>,
	Toshi Kani <toshi.kani@...com>,
	"Hart, Darren" <darren.hart@...el.com>,
	"saul.wold" <saul.wold@...el.com>, linux-kernel@...r.kernel.org,
	kvm ML <kvm@...r.kernel.org>, x86-ml <x86@...nel.org>
Subject: Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
 disabled"

On Fri, 2016-03-11 at 17:28 -0500, Bruce Ashfield wrote:
> On 2016-03-11 5:16 PM, Borislav Petkov wrote:
> > On Fri, Mar 11, 2016 at 08:18:23PM +0100, Paolo Bonzini wrote:
> > > Somebody got it wrong 10-ish years ago, and nobody has ever
> > > checked since.
> > > 
> > > But, don't use qemu32 or qemu64.  Use kvm32 and kvm64, or better
> > > something like the host you run on ("-cpu Nehalem", "-cpu
> > > SandyBridge",
> > > "-cpu Haswell-noTSX" etc.).
> > 
> > Paul, Richard, how about it?
> 
> I'm not Paul/Richard, but I can answer :)
> 
> We want a more generic cpu for these qemu references. Something that
> doesn't vary, since it runs on any number of hosts. There are some
> horrible issues we've had to solve with -cpu host in the past.
> 
> Switching to the kvm cpu type should work, plus we can add cpu
> extensions on the fly as necessary.
> 
> That's definitely a valid outcome from this discussion .. a cpu
> type that doesn't shoot through the middle of the expected
> capabilities .. and a bonus if the kernel or qemu can be tweaked
> to survive a similar mix up in the flags in the future.

We'll have to go and trawl our commit logs to figure out how we ended
up with choosing qemuXX, I do remember everything else we tried
previously broke in some way. We do need something which works on quite
a wide variety of systems and if I remember rightly, the CPU features
the kvm* options provide vary quite widely and wasn't consistent. The
qemu* ones at least consistently broke everywhere! :)

Tweaking the kernel to only enable PAT with MTRR sounds like a good
fix, as does fixing the qemu cpu feature bits and I'd like to get those
patches into our builds once they're heading into the upstreams.
Meanwhile we'll see if we can find a better cpu option as well.

Cheers,

Richard