All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	David Woodhouse <dwmw@amazon.co.uk>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors
Date: Tue, 23 Jan 2018 19:02:51 +0000	[thread overview]
Message-ID: <bb364dbb-4f16-56ab-c306-d96edea94dad@citrix.com> (raw)
In-Reply-To: <20180123173312.1d8cf02f@alans-desktop>

On 23/01/18 18:45, Alan Cox wrote:
> On Tue, 23 Jan 2018 16:52:55 +0000
> David Woodhouse <dwmw@amazon.co.uk> wrote:
>
>> When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
>> bit set, they don't need KPTI either.
> This is starting to get messy because we will eventually need to integrate
>
> AMD processors		-	no meltdown but spectre
> VIA processors		-	probably no vulnerabilities at
> 				least on the old ones
> Intel with ND set	-	No meltdown
> Anybody with no speculation -	No meltdown, no spectre, no id bit
>
>
>
> and it expands a lot with all sorts of 32bit processors. Would it make
> more sense to make it table driven or do we want a separate function so
> we can do:
>
>                 if (!in_order_cpu()) {
>                 }
>
> around the whole lot ? I'm guessing the latter makes sense then
> somethhing like this patch I'm running on my old atom widgets in 64bit
> mode
>
> static __initdata struct x86_cpu_id cpu_in_order[] = {
>         { 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 },
>         {}
> };
>
> static int in_order_cpu(void)
> {
> 	/* Processors with CPU id etc */
> 	if (x86_match_cpu(cpu_in_order))
> 		return 1;
> 	/* Other rules here */
> 	return 0;
> }

Why does in-order vs out-of-order matter?

There are leaky SP3 gadgets which satisfy in-order requirements, so long
as the processor is capable of speculating 3 instructions past an
unresolved branch.

What would (at a guess) save an in-order speculative processor from
being vulnerable is if memory reads are issued and resolve in program
order, but in that case, it is not the in-order property of the
processor which makes it safe.

~Andrew

  reply	other threads:[~2018-01-23 19:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 16:52 [PATCH v2 0/5] Basic Speculation Control feature support David Woodhouse
2018-01-23 16:52 ` [PATCH v2 1/5] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf David Woodhouse
2018-01-23 16:52 ` [PATCH v2 2/5] x86/cpufeatures: Add Intel feature bits for Speculation Control David Woodhouse
2018-01-23 18:43   ` Dave Hansen
2018-01-24  1:23     ` Woodhouse, David
2018-01-24  1:28       ` Dave Hansen
2018-01-24  8:13         ` Woodhouse, David
2018-01-23 16:52 ` [PATCH v2 3/5] x86/cpufeatures: Add AMD " David Woodhouse
2018-01-24  8:39   ` Kirill A. Shutemov
2018-01-24  8:40     ` David Woodhouse
2018-01-23 16:52 ` [PATCH v2 4/5] x86/msr: Add definitions for new speculation control MSRs David Woodhouse
2018-01-23 18:27   ` Dave Hansen
2018-01-23 18:31     ` Greg KH
2018-01-23 18:48       ` Woodhouse, David
2018-01-23 16:52 ` [PATCH v2 5/5] x86/pti: Do not enable PTI on fixed Intel processors David Woodhouse
2018-01-23 18:12   ` Andi Kleen
2018-01-24  1:21     ` David Woodhouse
2018-01-23 18:40   ` Dave Hansen
2018-01-24  1:27     ` David Woodhouse
2018-01-23 18:41   ` Dave Hansen
2018-01-23 18:44     ` Woodhouse, David
2018-01-23 18:45   ` Alan Cox
2018-01-23 19:02     ` Andrew Cooper [this message]
2018-01-23 20:45       ` Alan Cox
2018-01-23 20:38     ` Linus Torvalds
2018-01-23 20:50     ` David Woodhouse
2018-01-24 16:25     ` David Woodhouse
2018-01-24 17:07       ` Alan Cox
2018-01-24 17:42         ` David Woodhouse
2018-01-24 18:40           ` Alan Cox
2018-01-24 18:59             ` David Woodhouse
2018-01-24 19:37             ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bb364dbb-4f16-56ab-c306-d96edea94dad@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.