All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, r.marek@assembler.cz,
	ricardo.neri-calderon@linux.intel.com, rkrcmar@redhat.com,
	Janakarajan.Natarajan@amd.com, bp@suse.de, x86@kernel.org,
	hpa@zytor.com, mingo@redhat.com,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] clarify how insecure CPU is
Date: Sun, 4 Mar 2018 09:51:59 +0100	[thread overview]
Message-ID: <20180304085159.GB7931@amd> (raw)
In-Reply-To: <alpine.DEB.2.21.1803040825130.1654@nanos.tec.linutronix.de>

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

Hi!

> > > > > > 
> > > > > > First, what is going on with X86_BUG_AMD_E400 and X86_BUG_AMD_APIC_C1E
> > > > > > ? They seem to refer to the same bug, perhaps comment should mention
> > > > > > that? (Do we need two flags for one bug?)
> > > > > > 
> > > > > > Next, maybe X86_BUG_CPU_INSECURE is a bit too generic? This seems to
> > > > > > address "Meltdown" problem, but not "Spectre". Should it be limited to
> > > > > > PPro and newer Intel CPUs?
> > > > > > 
> > > > > > Should another erratum be added for "Spectre"? This is present even on
> > > > > > AMD CPUs, but should not be present in 486, maybe Pentium, and some
> > > > > > Atom chips?
> > > > > > 
> > > > > > Plus... is this reasonable interface?
> > > > > > 
> > > > > > bugs		: cpu_insecure
> > > > > 
> > > > > We've renamed it to meltdown already and added spectre_v1/v2 bits for the
> > > > > rest of the mess.
> > > > 
> > > > Could you explain (best with code comment) what is going on with
> > > > X86_BUG_AMD_E400 and X86_BUG_AMD_APIC_C1E ? They seem to refer to the
> > > > same bug.
> > > 
> > > Sorry, that;s really not the time for this.
> > 
> > Ok, is there better time now? The code is a bit confusing...
> 
> What's confusing? Here are the relevant code snippets in invocation order.
> 
> 	/*
> 	 * Check whether the machine is affected by erratum 400. This is
> 	 * used to select the proper idle routine and to enable the check
> 	 * whether the machine is affected in arch_post_acpi_init(), which
> 	 * sets the X86_BUG_AMD_APIC_C1E bug depending on the MSR check.
> 	 */
> 	if (cpu_has_amd_erratum(c, amd_erratum_400))
> 		set_cpu_bug(c, X86_BUG_AMD_E400);
> 
> This sets the errate 400 bug bit to tell subsequent code that the CPU might
> be affected by that erratum.
> 
> void select_idle_routine(const struct cpuinfo_x86 *c)
> {
> 
> 	if (boot_cpu_has_bug(X86_BUG_AMD_E400)) {
> 		pr_info("using AMD E400 aware idle routine\n");
> 		x86_idle = amd_e400_idle;
> 
> Selects the idle routine depending on the bug flag
> 
> void __init arch_post_acpi_subsys_init(void)
> {
> 	u32 lo, hi;
> 
> 	if (!boot_cpu_has_bug(X86_BUG_AMD_E400))
> 		return;
> 
> 	/*
> 	 * AMD E400 detection needs to happen after ACPI has been enabled. If
> 	 * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set in
> 	 * MSR_K8_INT_PENDING_MSG.
> 	 */
> 	rdmsr(MSR_K8_INT_PENDING_MSG, lo, hi);
> 	if (!(lo & K8_INTP_C1E_ACTIVE_MASK))
> 		return;
> 
> Late detection whether C1E which halts TSC and APIC is enabled. This needs
> to be done after ACPI is initialized.
> 
> /*
>  * AMD Erratum 400 aware idle routine. We handle it the same way as C3 power
>  * states (local apic timer and TSC stop).
>  */
> static void amd_e400_idle(void)
> {
> 	/*
> 	 * We cannot use static_cpu_has_bug() here because X86_BUG_AMD_APIC_C1E
> 	 * gets set after static_cpu_has() places have been converted via
> 	 * alternatives.
> 	 */
> 	if (!boot_cpu_has_bug(X86_BUG_AMD_APIC_C1E)) {
> 		default_idle();
> 		return;
> 	}
> 
> The actual idle routine. If the C1E bug flag is not set, CPU is not
> affected, use default idle, otherwise handle it like other C-States which
> stop TSC and APIC.
> 
> 
> The comments are clear enough, but Feel free to send patches which enhance
> them if you think thats necessary.

Thanks for explanation. Might this be good idea?

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index f41079d..4901742 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -341,7 +341,7 @@
 #define X86_BUG_FDIV			X86_BUG(1) /* FPU FDIV */
 #define X86_BUG_COMA			X86_BUG(2) /* Cyrix 6x86 coma */
 #define X86_BUG_AMD_TLB_MMATCH		X86_BUG(3) /* "tlb_mmatch" AMD Erratum 383 */
-#define X86_BUG_AMD_APIC_C1E		X86_BUG(4) /* "apic_c1e" AMD Erratum 400 */
+#define X86_BUG_AMD_APIC_C1E		X86_BUG(4) /* System is affected AMD Erratum 400, special idle routine is needed */
 #define X86_BUG_11AP			X86_BUG(5) /* Bad local APIC aka 11AP */
 #define X86_BUG_FXSAVE_LEAK		X86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */
 #define X86_BUG_CLFLUSH_MONITOR		X86_BUG(7) /* AAI65, CLFLUSH required before MONITOR */
@@ -356,7 +356,7 @@
 #define X86_BUG_NULL_SEG		X86_BUG(10) /* Nulling a selector preserves the base */
 #define X86_BUG_SWAPGS_FENCE		X86_BUG(11) /* SWAPGS without input dep on GS */
 #define X86_BUG_MONITOR			X86_BUG(12) /* IPI required to wake up remote CPU */
-#define X86_BUG_AMD_E400		X86_BUG(13) /* CPU is among the affected by Erratum 400 */
+#define X86_BUG_AMD_E400		X86_BUG(13) /* System may be affected by Erratum 400, X86_BUG_AMD_APIC_C1E might be needed  */
 #define X86_BUG_CPU_MELTDOWN		X86_BUG(14) /* CPU is affected by meltdown attack and needs kernel page table isolation */
 #define X86_BUG_SPECTRE_V1		X86_BUG(15) /* CPU is affected by Spectre variant 1 attack with conditional branches */
 #define X86_BUG_SPECTRE_V2		X86_BUG(16) /* CPU is affected by Spectre variant 2 attack with indirect branches */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2018-03-04  8:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08 20:10 [PATCH] clarify how insecure CPU is Pavel Machek
2018-01-08 20:27 ` Thomas Gleixner
2018-01-08 23:03   ` Pavel Machek
2018-01-08 23:44     ` Thomas Gleixner
2018-03-03 21:06       ` Pavel Machek
2018-03-04  7:34         ` Thomas Gleixner
2018-03-04  8:51           ` Pavel Machek [this message]
2018-03-04  9:29             ` Borislav Petkov
2018-03-04 14:01               ` Pavel Machek
2018-03-04 14:27                 ` Borislav Petkov

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=20180304085159.GB7931@amd \
    --to=pavel@ucw.cz \
    --cc=Janakarajan.Natarajan@amd.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=r.marek@assembler.cz \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --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.