From: Andi Kleen <ak@linux.intel.com>
To: speck@linutronix.de
Cc: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] [PATCH v5 6/8] L1TFv4 4
Date: Wed, 23 May 2018 14:51:23 -0700 [thread overview]
Message-ID: <91e496b5008ec0b84c29a545c716a16fb91814fa.1527111786.git.ak@linux.intel.com> (raw)
In-Reply-To: <cover.1527111786.git.ak@linux.intel.com>
In-Reply-To: <cover.1527111786.git.ak@linux.intel.com>
If the system has more than MAX_PA/2 physical memory the
invert page workarounds don't protect the system against
the L1TF attack anymore, because an inverted physical address
will point to valid memory.
We cannot do much here, after all users want to use the
memory, but at least print a warning and report the system as
vulnerable in sysfs
Note this is all extremely unlikely to happen on a real machine
because they typically have far more MAX_PA than DIMM slots
Some VMs also report fairly small PAs to guest, e.g. only 36bits.
In this case the threshold will be lower, but applies only
to the maximum guest size.
Since this needs to clear a feature bit that has been forced
earlier add a special "unforce" macro that supports this.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
squash! x86, l1tf: Report if too much memory for L1TF workaround
v2:
Do force clearing in setup_clear_...
Rename variables, fix comments, change formatting.
Use l1tf_pfn_limit()
---
arch/x86/kernel/cpu/cpuid-deps.c | 1 +
arch/x86/kernel/setup.c | 23 ++++++++++++++++++++++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 2c0bd38a44ab..ffb178fe6356 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -118,4 +118,5 @@ void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature)
void setup_clear_cpu_cap(unsigned int feature)
{
do_clear_cpu_cap(NULL, feature);
+ clear_bit(feature, (unsigned long *)cpu_caps_set);
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 443e31c33fa6..99155e9b28c4 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -785,7 +785,26 @@ static void __init trim_low_memory_range(void)
{
memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
}
-
+
+static __init void check_maxpa_memory(void)
+{
+ u64 half_pa;
+
+ if (!boot_cpu_has(X86_BUG_L1TF))
+ return;
+
+ half_pa = (u64)l1tf_pfn_limit() << PAGE_SHIFT;
+
+ /*
+ * This is extremely unlikely to happen because almost all systems have far
+ * more MAX_PA/2 than DIMM slots.
+ */
+ if (e820__mapped_any(half_pa, ULLONG_MAX - half_pa, E820_TYPE_RAM)) {
+ pr_warn("System has more than MAX_PA/2 memory. Disabled L1TF workaround\n");
+ setup_clear_cpu_cap(X86_FEATURE_L1TF_WA);
+ }
+}
+
/*
* Dump out kernel offset information on panic.
*/
@@ -1022,6 +1041,8 @@ void __init setup_arch(char **cmdline_p)
insert_resource(&iomem_resource, &data_resource);
insert_resource(&iomem_resource, &bss_resource);
+ check_maxpa_memory();
+
e820_add_kernel_range();
trim_bios_range();
#ifdef CONFIG_X86_32
--
2.14.3
next prev parent reply other threads:[~2018-05-23 21:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 21:51 [MODERATED] [PATCH v5 0/8] L1TFv4 5 Andi Kleen
2018-05-23 21:51 ` [MODERATED] [PATCH v5 1/8] L1TFv4 6 Andi Kleen
2018-05-23 21:51 ` [MODERATED] [PATCH v5 2/8] L1TFv4 7 Andi Kleen
2018-05-23 21:51 ` [MODERATED] [PATCH v5 3/8] L1TFv4 2 Andi Kleen
2018-05-23 21:51 ` [MODERATED] [PATCH v5 4/8] L1TFv4 8 Andi Kleen
2018-05-23 21:51 ` [MODERATED] [PATCH v5 5/8] L1TFv4 0 Andi Kleen
2018-05-23 21:51 ` Andi Kleen [this message]
2018-05-23 21:51 ` [MODERATED] [PATCH v5 7/8] L1TFv4 3 Andi Kleen
2018-05-23 21:51 ` [MODERATED] [PATCH v5 8/8] L1TFv4 1 Andi Kleen
[not found] ` <20180523215658.63CAB61104@crypto-ml.lab.linutronix.de>
2018-05-23 22:22 ` [MODERATED] Re: [PATCH v5 5/8] L1TFv4 0 Borislav Petkov
[not found] ` <20180523215726.A931B61157@crypto-ml.lab.linutronix.de>
2018-05-23 22:50 ` [MODERATED] Re: [PATCH v5 8/8] L1TFv4 1 Dave Hansen
[not found] ` <20180523215737.7C50E61169@crypto-ml.lab.linutronix.de>
2018-05-23 23:15 ` [MODERATED] Re: [PATCH v5 1/8] L1TFv4 6 Dave Hansen
2018-05-23 23:52 ` Andrew Cooper
2018-05-24 9:09 ` Michal Hocko
2018-05-24 15:26 ` Andi Kleen
2018-05-24 17:00 ` Dave Hansen
[not found] ` <20180523215136.EB16B610ED@crypto-ml.lab.linutronix.de>
2018-05-24 3:34 ` [MODERATED] Re: [PATCH v5 4/8] L1TFv4 8 Josh Poimboeuf
[not found] ` <20180523215651.BFF82610ED@crypto-ml.lab.linutronix.de>
2018-05-24 4:04 ` [MODERATED] Re: [PATCH v5 6/8] L1TFv4 4 Josh Poimboeuf
2018-05-24 13:35 ` Andi Kleen
2018-05-24 15:45 ` Josh Poimboeuf
2018-05-24 16:53 ` Andi Kleen
2018-05-24 17:53 ` Josh Poimboeuf
2018-05-24 20:32 ` Andi Kleen
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=91e496b5008ec0b84c29a545c716a16fb91814fa.1527111786.git.ak@linux.intel.com \
--to=ak@linux.intel.com \
--cc=speck@linutronix.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).