AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Signed-off-by: Tom Lendacky <[email protected]>
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c47de4e..7d9e3b0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
fpu__init_system(c);
On 12/26/2017 09:43 PM, Tom Lendacky wrote:
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>
> setup_force_cpu_cap(X86_FEATURE_ALWAYS);
>
> - /* Assume for now that ALL x86 CPUs are insecure */
> - setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
> + if (c->x86_vendor != X86_VENDOR_AMD)
> + setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
Does this disable it in a way that it can be turned back on via the
kernel command-line?
This is a rather wide class of issues and I would rather not just
hard-code it in a way that we say one vendor has never and will never be
affected.
On 12/27/2017 2:48 AM, Dave Hansen wrote:
> On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>>
>> setup_force_cpu_cap(X86_FEATURE_ALWAYS);
>>
>> - /* Assume for now that ALL x86 CPUs are insecure */
>> - setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
>> + if (c->x86_vendor != X86_VENDOR_AMD)
>> + setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
>
> Does this disable it in a way that it can be turned back on via the
> kernel command-line?
>
Yes, specifying pti=on on the command line will turn kernel page table
isolation on regardless of this setting.
Thanks,
Tom
> This is a rather wide class of issues and I would rather not just
> hard-code it in a way that we say one vendor has never and will never be
> affected.
>
On Tue, Dec 26, 2017 at 11:43:54PM -0600, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access higher privileged data when running in a lesser privileged mode
> when that access would result in a page fault.
>
> Disable page table isolation by default on AMD processors by not setting
> the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
> is set.
>
> Signed-off-by: Tom Lendacky <[email protected]>
> ---
> arch/x86/kernel/cpu/common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index c47de4e..7d9e3b0 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>
> setup_force_cpu_cap(X86_FEATURE_ALWAYS);
>
> - /* Assume for now that ALL x86 CPUs are insecure */
> - setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
> + if (c->x86_vendor != X86_VENDOR_AMD)
> + setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
>
> fpu__init_system(c);
Reviewed-by: Borislav Petkov <[email protected]>
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Why this wonderful tiny patch by Tom Lendacky is still not merged? If
it is just Intel who made these insecure CPUs , for which this
"slowdown workaround" is required, ---> why the AMD CPU owners should
suffer from Intel's design faults ? " cpu_insecure " is Intel's
problem ; according to Tom Lendacky from AMD - AMD CPUs do not need
this "slowdown workaround" which is required for Intel CPUs. Please
merge this patch as soon as possible
Of course, the Intel employees would be happy to see this patch get
delayed or even not merged, because its a shame and bad reputation for
their company and products :
>
> I would rather not just hard-code it in a way that we say one vendor has never and will never be affected
>
> --- by Dave Hansen from Intel corporation
>
Luckily, according to LKML - a message with Tom's patch is the Top
Hottest Message viewed ! The fate of this patch is being closely
monitored by the people all over the world, and hopefully the Linux
community will not allow any injustice to happen
On Tue, Dec 26, 2017 at 11:43:54PM -0600, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access higher privileged data when running in a lesser privileged mode
> when that access would result in a page fault.
>
> Disable page table isolation by default on AMD processors by not setting
> the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
> is set.
>
> Signed-off-by: Tom Lendacky <[email protected]>
> ---
> arch/x86/kernel/cpu/common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index c47de4e..7d9e3b0 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>
> setup_force_cpu_cap(X86_FEATURE_ALWAYS);
>
> - /* Assume for now that ALL x86 CPUs are insecure */
> - setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
> + if (c->x86_vendor != X86_VENDOR_AMD)
> + setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
>
> fpu__init_system(c);
Reviewed-by: Ivan Ivanov <[email protected]>
Best regards,
Ivan Ivanov,
coreboot project developer
and open-source enthusiast
Commit-ID: 694d99d40972f12e59a3696effee8a376b79d7c8
Gitweb: https://git.kernel.org/tip/694d99d40972f12e59a3696effee8a376b79d7c8
Author: Tom Lendacky <[email protected]>
AuthorDate: Tue, 26 Dec 2017 23:43:54 -0600
Committer: Thomas Gleixner <[email protected]>
CommitDate: Wed, 3 Jan 2018 15:57:59 +0100
x86/cpu, x86/pti: Do not enable PTI on AMD processors
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Signed-off-by: Tom Lendacky <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f2a94df..b1be494 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -899,8 +899,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
fpu__init_system(c);
On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>AMD processors are not subject to the types of attacks that the kernel page table isolation
feature protects against.
There is no doubt this is a serious flaw. This thread reminded me - about a year ago we
discovered a software code that bricked an Intel CPU. The software code was executed and
the processor seized. The Motherboard was reset via the reset button, but the processor
never came back. It was rather dead - the CPU did not even draw any power. We contacted
Intel and one of their personnel suggested that they were aware of it. I never quite
understood if it was a processor feature or a flaw.
Tim
On Mon, Feb 12, 2018 at 10:26 AM, Pavel Machek <[email protected]> wrote:
> On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
>> AMD processors are not subject to the types of attacks that the kernel
>> page table isolation feature protects against. The AMD microarchitecture
>> does not allow memory references, including speculative references, that
>> access higher privileged data when running in a lesser privileged mode
>> when that access would result in a page fault.
>>
>> Disable page table isolation by default on AMD processors by not setting
>> the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
>> is set.
>
> PTI was originally meant to protect KASLR from memory leaks, before
> Spectre was public. I guess that's still valid use on AMD cpus?
> Pavel
KASLR leaks are a much lower threat than Meltdown. Given that no AMD
processor supports PCID, enabling PTI has a much more significant
performance impact for a much smaller benefit. For the paranoid user
they still have the option to enable PTI at boot, but it should not be
on by default.
--
Brian Gerst
On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access higher privileged data when running in a lesser privileged mode
> when that access would result in a page fault.
>
> Disable page table isolation by default on AMD processors by not setting
> the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
> is set.
PTI was originally meant to protect KASLR from memory leaks, before
Spectre was public. I guess that's still valid use on AMD cpus?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 12 Feb 2018, Pavel Machek wrote:
> On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
> > AMD processors are not subject to the types of attacks that the kernel
> > page table isolation feature protects against. The AMD microarchitecture
> > does not allow memory references, including speculative references, that
> > access higher privileged data when running in a lesser privileged mode
> > when that access would result in a page fault.
> >
> > Disable page table isolation by default on AMD processors by not setting
> > the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
> > is set.
>
> PTI was originally meant to protect KASLR from memory leaks, before
> Spectre was public. I guess that's still valid use on AMD cpus?
The KASLR attacks against which PTI protects are not based on a memory
leak. The KASLR attacks are revealing the kernel virtual address space w/o
revealing any data.
Quite some of those attacks can be mitigated via PTI, but only some of the
attacks work on AMD CPUs. The bulk (and easy to conduct) attacks do not
work work on AMD CPUs due to the same reason why Meltdown does not work.
Thanks,
tglx