linux-kernel - Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors

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:   Wed, 24 Jan 2018 17:42:03 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel
 processors

On Wed, 2018-01-24 at 17:07 +0000, Alan Cox wrote:
> > 
> >  
> > +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
> > +	{ X86_VENDOR_AMD },
> > +	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> > +	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
> > +	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
> > +	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
> > +	{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
> As Linus said this should be no_specualtion[]
> 
> If we are going to capture 32bit here with your lines below I'll send you
> an update at some point with all the 32bit families hunted down (some
> like the CE4100 may take a bit of hunting)
> 
> 
> > 
> > +	{ X86_VENDOR_ANY, 5 },
> AND K5 speculates, Cyrix 6x86 speculates, IDT WinChip does not. I think
> this should be
> 
> X86_VENDOR_ANY, 4
> X86_VENDOR_INTEL, 5,
> X86_VENDOR_CENTAUR, 5,

Hm, for the specific case of controlling X86_BUG_CPU_MELTDOWN it's not
just "speculates" which is the criterion. It's "optimises away the
permissions checks while speculating, on the assumption that it'll be
fixed up before retiring the instruction".

I think X86_BUG_CPU_SPECTRE_V2 might end being a lot closer to just "it
speculates".

> > 
> > +static bool __init early_cpu_vulnerable_meltdown(struct cpuinfo_x86 *c)
> > +{
> > +	u64 ia32_cap = 0;
> > +
> > +	if (x86_match_cpu(cpu_no_meltdown))
> > +                return false;
> These processors are also not vulnerable to spectre, so this patch
> doesn't set the other flags correctly - that's why we need two levels of
> logic here. "Bonnell" and "Saltwell" uarch Atom processors are not
> vulnerable to Meltdown or Spectre, neithr is a 486, Pentium, Quark etc.

Yeah, I've deliberately not touched Spectre for this case.

By the time the dust settles we might end up with a bunch of different
match tables, *one* of which is "does not speculate at all". And the
conditions for the different bugs will each use different sets of match
tables. For example

 if (!x86_match_cpu(cpu_no_speculation_at_all) &&
     !x86_match_cpu(speculation_but_no_meltdown) &&
     !cpu_sets_rdcl_no())
	setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);

 if (!x86_match_cpu(cpu_no_speculation_at_all) &&
     !x86_match_cpu(no_branch_target_buffer))
	setup_force_cpu_bug(X86_BUG_SPECTRE_V2);

...


Let's gather the data and see how we want to break it down according to
which subsets are common. In the mean time Meltdown is the big one
which has performance implications and wants to be avoided if we can.


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)