Patch 5
PATCH 5/6 Patch 5
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
Typical MAX_PA sizes on Intel and respective threshold:
Nehalem Client 39 >=0.25TB
Nehalem Server 44 >=8TB
SandyBridge/IvyBridge/Haswell/Broadwell/Skylake 46 >=32TB
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.
--- arch/x86/kernel/setup.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
arch/x86/kernel/setup.c +23 -1
@@ -779,7 +779,27 @@ static void __init trim_low_memory_range(void) {memblock_reserve (0 ,ALIGN (reserve_low,PAGE_SIZE )); } - + +static __init void check_maxpa_memory (void ) +{ +u64 len; + +if (!boot_cpu_has (X86_BUG_L1TF )) +return ; + + len = (1ULL << (boot_cpu_data.x86_phys_bits -1 )) -1 ; + +/* +* This is extremely unlikely to happen because systems near always have far +* more MAX_PA than DIMM slots. +*/ +if (e820__mapped_any (len,ULLONG_MAX - len, +E820_TYPE_RAM )) { +pr_warn ("System has more than MAX_PA/2 memory. Disabled L1TF workaround\n" ); +setup_force_cpu_cap (X86_FEATURE_NO_L1TF_FIX ); + } +} +/* * Dump out kernel offset information on panic. */
@@ -1016,6 +1036,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
Signature · 1 line
2.15.0