From: Pavel Machek <pavel@ucw.cz>
To: 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, tglx@linutronix.de
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH] clarify how insecure CPU is
Date: Mon, 8 Jan 2018 21:10:17 +0100 [thread overview]
Message-ID: <20180108201017.GA20588@amd> (raw)
[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]
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
I believe we should
a) have something more descriptive than 'cpu_insecure', like
'mem_always_r' (because poor user has no chance to know if it is
Meltdown, Spectre, or something else)
b) have has_meltdown : yes/no, because otherwise poor userspace can
not tell if CPU is actually bug-free, or if the kernel is just too old
to know about specific bug. With all the backport, this is quite important.
Best regards,
Pavel
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 07cdd17..d46958e 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -340,7 +340,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_CPU_INSECURE X86_BUG(14) /* CPU is insecure and needs kernel page table isolation */
+#define X86_BUG_AMD_E400 X86_BUG(13) /* CPU is among the affected by Erratum 400, check for X86_BUG_AMD_APIC_C1E */
+#define X86_BUG_CPU_INSECURE X86_BUG(14) /* CPU always allows reading mapped memory, aka "Meltdown", kernel page table isolation needed */
#endif /* _ASM_X86_CPUFEATURES_H */
--
(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 --]
next reply other threads:[~2018-01-08 20:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 20:10 Pavel Machek [this message]
2018-01-08 20:27 ` [PATCH] clarify how insecure CPU is 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
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=20180108201017.GA20588@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox