All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Yves-Alexis Perez <corsac@debian.org>,
	arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org,
	pbonzini@redhat.com, ak@linux.intel.com,
	torvalds@linux-foundation.org, gregkh@linux-foundation.org,
	dave.hansen@intel.com, gnomes@lxorguk.ukuu.org.uk
Subject: Re: [PATCH v3 5/6] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown
Date: Fri, 26 Jan 2018 12:27:11 +0000	[thread overview]
Message-ID: <1516969631.30244.215.camel@infradead.org> (raw)
In-Reply-To: <1516968886.19619.7.camel@debian.org>

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

On Fri, 2018-01-26 at 13:14 +0100, Yves-Alexis Perez wrote:
> On Wed, 2018-01-24 at 16:57 +0000, David Woodhouse wrote:
> > Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise
> > the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not vulnerable.
> > 
> > Roll the AMD exemption into the x86_match_cpu() table too.
> > 
> > Based on suggestions from Dave Hansen and Alan Cox.
> 
> Hi David,
> 
> I know we'll still be able to manually enable PTI with a command line option,
> but it's also a hardening feature which has the nice side effect of emulating
> SMEP on CPU which don't support it (e.g the Atom boxes above).
> 
> Couldn't we keep the “default on”? Or maybe on boxes which also have CPID (in
> order to limit the performance cost)?

Strictly speaking, "don't enable PTI" is a side-effect of my patch, not
directly what it does.

All this patch does is *correctly* refrain from setting
X86_BUG_CPU_MELTDOWN on CPUs which don't suffer that bug.

It's the logic in arch/x86/mm/pti.c which enables PTI by default only
for CPUs with the the bug.

As for whether PCID reduces the performance hit sufficiently to make it worthwhile, "just" to emulate SMEP, I'm not sure. But I am sure it's someone else's problem for today except as a cosmetic comment on the headline of my patch :)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

  reply	other threads:[~2018-01-26 12:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-24 16:56 [PATCH v3 0/6] Basic Speculation Control feature support David Woodhouse
2018-01-24 16:57 ` [PATCH v3 1/6] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf David Woodhouse
2018-01-24 17:18   ` Greg KH
2018-01-24 16:57 ` [PATCH v3 2/6] x86/cpufeatures: Add Intel feature bits for Speculation Control David Woodhouse
2018-01-24 17:18   ` Greg KH
2018-01-24 16:57 ` [PATCH v3 3/6] x86/cpufeatures: Add AMD " David Woodhouse
2018-01-24 17:20   ` Greg KH
2018-01-24 17:57     ` David Woodhouse
2018-01-24 22:52       ` Tom Lendacky
2018-02-20 15:22         ` Tom Lendacky
2018-01-24 16:57 ` [PATCH v3 4/6] x86/msr: Add definitions for new speculation control MSRs David Woodhouse
2018-01-24 17:16   ` Greg KH
2018-01-24 16:57 ` [PATCH v3 5/6] x86/pti: Do not enable PTI on processors which are not vulnerable to Meltdown David Woodhouse
2018-01-24 17:26   ` Greg KH
2018-01-26 12:14   ` Yves-Alexis Perez
2018-01-26 12:27     ` David Woodhouse [this message]
2018-01-26 15:27     ` Dave Hansen
2018-01-26 15:30       ` Arjan van de Ven
2018-01-26 16:47     ` Alan Cox
2018-01-24 16:57 ` [PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes David Woodhouse
2018-01-24 17:29   ` Greg KH
2018-01-24 17:58     ` David Woodhouse
2018-01-24 21:29     ` Ingo Molnar
2018-01-26 12:16   ` Yves-Alexis Perez
2018-01-26 12:27     ` 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=1516969631.30244.215.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=corsac@debian.org \
    --cc=dave.hansen@intel.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linux-foundation.org \
    --cc=karahmed@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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.