DM&P devices were not being properly identified, which resulted in
unneeded Spectre/Meltdown mitigations being applied.
The manufacturer states that these devices execute always in-order and
don't support either speculative execution or branch prediction, so
they are not vulnerable to this class of attack. [1]
This is something I've personally tested by a simple timing analysis
on my Vortex86MX CPU, and can confirm it is true.
Identification for some devices that lack the CPUID product name call
has also been added, so they appear properly on /proc/cpuinfo.
1: https://www.ssv-embedded.de/doks/infos/DMP_Ann_180108_Meltdown.pdf
Signed-off-by: Marcos Del Sol Vives <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: [email protected]
---
arch/x86/Kconfig.cpu | 14 ++++++++++++
arch/x86/include/asm/processor.h | 3 ++-
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/common.c | 2 ++
arch/x86/kernel/cpu/dmp.c | 39 ++++++++++++++++++++++++++++++++
5 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/kernel/cpu/dmp.c
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 814fe0d349b0..8a110f4a1ec3 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -508,3 +508,17 @@ config CPU_SUP_ZHAOXIN
CPU might render the kernel unbootable.
If unsure, say N.
+
+config CPU_SUP_DMP_32
+ default y
+ bool "Support DM&P processors" if PROCESSOR_SELECT
+ depends on !64BIT
+ help
+ This enables detection, tunings and quirks for DM&P processors
+
+ You need this enabled if you want your kernel to run on a
+ DM&P CPU. Disabling this option on other types of CPUs
+ makes the kernel a tiny bit smaller. Disabling it on a DM&P
+ CPU might render the kernel unbootable.
+
+ If unsure, say N.
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 9ad2acaaae9b..ac2700806b6e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -164,7 +164,8 @@ enum cpuid_regs_idx {
#define X86_VENDOR_NSC 8
#define X86_VENDOR_HYGON 9
#define X86_VENDOR_ZHAOXIN 10
-#define X86_VENDOR_NUM 11
+#define X86_VENDOR_DMP 11
+#define X86_VENDOR_NUM 12
#define X86_VENDOR_UNKNOWN 0xff
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 637b499450d1..37322107b773 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
obj-$(CONFIG_CPU_SUP_ZHAOXIN) += zhaoxin.o
+obj-$(CONFIG_CPU_SUP_DMP_32) += dmp.o
obj-$(CONFIG_X86_MCE) += mce/
obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 0f8885949e8c..ef2f7da8fb65 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1044,6 +1044,8 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
VULNWL(CENTAUR, 5, X86_MODEL_ANY, NO_SPECULATION),
VULNWL(INTEL, 5, X86_MODEL_ANY, NO_SPECULATION),
VULNWL(NSC, 5, X86_MODEL_ANY, NO_SPECULATION),
+ VULNWL(DMP, 5, X86_MODEL_ANY, NO_SPECULATION),
+ VULNWL(DMP, 6, X86_MODEL_ANY, NO_SPECULATION),
/* Intel Family 6 */
VULNWL_INTEL(ATOM_SALTWELL, NO_SPECULATION | NO_ITLB_MULTIHIT),
diff --git a/arch/x86/kernel/cpu/dmp.c b/arch/x86/kernel/cpu/dmp.c
new file mode 100644
index 000000000000..035f6dd99065
--- /dev/null
+++ b/arch/x86/kernel/cpu/dmp.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/kernel.h>
+#include <asm/processor.h>
+#include "cpu.h"
+
+/*
+ * No special init required for DM&P processors.
+ */
+
+static const struct cpu_dev dmp_cpu_dev = {
+ .c_vendor = "DM&P",
+ .c_ident = { "Vortex86 SoC" },
+ .legacy_models = {
+ {
+ .family = 5,
+ .model_names = {
+ [2] = "Vortex86DX",
+ [8] = "Vortex86MX",
+ },
+ },
+ {
+ .family = 6,
+ .model_names = {
+ /*
+ * Both the Vortex86EX and the Vortex86EX2
+ * have the same family and model id.
+ *
+ * However, the -EX2 supports the product name
+ * CPUID call, so this name will only be used
+ * for the -EX, which does not.
+ */
+ [0] = "Vortex86EX",
+ },
+ },
+ },
+ .c_x86_vendor = X86_VENDOR_DMP,
+};
+
+cpu_dev_register(dmp_cpu_dev);
--
2.25.1
On Fri, Oct 08, 2021 at 06:22:46PM +0200, Marcos Del Sol Vives wrote:
> +config CPU_SUP_DMP_32
> + default y
> + bool "Support DM&P processors" if PROCESSOR_SELECT
> + depends on !64BIT
You mean
depends on X86_32
?
Wikipedia says those things are 32-bit.
> + help
> + This enables detection, tunings and quirks for DM&P processors
> +
> + You need this enabled if you want your kernel to run on a
> + DM&P CPU. Disabling this option on other types of CPUs
So I'm not sure about the nomenclature: those CPUs are called Vortex86
and DM&P is simply the next owner of the IP:
"Vortex86 previously belonged to SiS, which got the basic design from
Rise Technology.[1] SiS sold it to DM&P Electronics[2] in Taiwan."
So I'm thinking we should call everything Vortex, the file vortex.c, the
vendor define X86_VENDOR_VORTEX and so on.
> + makes the kernel a tiny bit smaller. Disabling it on a DM&P
> + CPU might render the kernel unbootable.
Why unbootable? It looks like those are perfect clones: "No special init
required for DM&P processors." it says in the patch. :)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
El 13/10/2021 a las 16:57, Borislav Petkov escribió:
> On Fri, Oct 08, 2021 at 06:22:46PM +0200, Marcos Del Sol Vives wrote:
>> +config CPU_SUP_DMP_32
>> + default y
>> + bool "Support DM&P processors" if PROCESSOR_SELECT
>> + depends on !64BIT
>
> You mean
>
> depends on X86_32
>
> ?
>
> Wikipedia says those things are 32-bit.
>
I used here !64BIT because it is what CPU_SUP_TRANSMETA_32 and
CPU_SUP_UMC_32 (the only other two 32-bit-only processors on
Kconfig.cpu) are also using.
Using X86_32 makes total sense, in fact I originally used that, but for
consistency I changed it to !64BIT to match existing flags.
Should I change it then? Should I also change the other two, possibly in
a different patch?
>> + help
>> + This enables detection, tunings and quirks for DM&P processors
>> +
>> + You need this enabled if you want your kernel to run on a
>> + DM&P CPU. Disabling this option on other types of CPUs
>
> So I'm not sure about the nomenclature: those CPUs are called Vortex86
> and DM&P is simply the next owner of the IP:
>
> "Vortex86 previously belonged to SiS, which got the basic design from
> Rise Technology.[1] SiS sold it to DM&P Electronics[2] in Taiwan."
>
> So I'm thinking we should call everything Vortex, the file vortex.c, the
> vendor define X86_VENDOR_VORTEX and so on.
Makes total sense. Will change it for v2.
>> + makes the kernel a tiny bit smaller. Disabling it on a DM&P
>> + CPU might render the kernel unbootable.
>
> Why unbootable? It looks like those are perfect clones: "No special init
> required for DM&P processors." it says in the patch. :)
>
I used that text because it's what every other x86 processor flag is
also using, even those that also do not do any special initialization.
For example, the CPU_SUP_UMC_32 flag also has the same warning, yet
arch/x86/kernel/cpu/umc.c reads "UMC chips appear to be only either 386
or 486, so no special init takes place". I thus assumed this was
standard text, in case at some point an special init is required.
Do you think it should be then reworded, or should I keep it to mantain
consistency with other existing flag descriptions?
Greetings and thanks for your time,
Marcos
On Thu, Oct 14, 2021 at 06:29:12PM +0000, Marcos Del Sol Vives wrote:
> Should I change it then?
Yes please.
> Should I also change the other two, possibly in a different patch?
So I looked at
8d02c2110b3f ("x86: configuration options to compile out x86 CPU support code")
which added some of those !64_BIT deps. And when you look at
config X86_32
def_bool !64BIT
and having those items either depend on "!64BIT" or on "X86_32" should
be equivalent. Former is just weird to have in other Kconfig items
except X86_32.
So yes, please, in a separate patch.
> I used that text because it's what every other x86 processor flag is
> also using, even those that also do not do any special initialization.
>
> For example, the CPU_SUP_UMC_32 flag also has the same warning, yet
> arch/x86/kernel/cpu/umc.c reads "UMC chips appear to be only either 386
> or 486, so no special init takes place". I thus assumed this was
> standard text, in case at some point an special init is required.
Yah, sounds like they've all been copy-pasted from some item which
really needs special init.
> Do you think it should be then reworded, or should I keep it to mantain
> consistency with other existing flag descriptions?
Yeah, please write the correct statement in there and do not take the
other entries too seriosly - looks like semi-automatic copy-paste took
place.
> Greetings and thanks for your time,
Ditto and you're welcome!
:-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette