lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 24 Aug 2018 04:22:57 +0200
From:   Andre Tomt <andre@...t.net>
To:     Andi Kleen <ak@...ux.intel.com>, Vlastimil Babka <vbabka@...e.cz>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Michal Hocko <mhocko@...nel.org>, stable@...r.kernel.org,
        Christopher Snowhill <kode54@...il.com>,
        George Anchev <studio@...hev.net>
Subject: Re: [PATCH] x86/speculation/l1tf: fix off-by-one error when warning
 that system has too much RAM

On 23. aug. 2018 17:44, Andi Kleen wrote:
> On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
>> Two users have reported [1] that they have an "extremely unlikely" system
>> with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact
>> it's a CPU with 36bits phys limit (64GB) and 32GB memory, but due to holes
>> in the e820 map, the main region is almost 500MB over the 32GB limit:
> 
> Ah I see it's a client part with very large DIMMs and someone being
> very brave and using that much memory without ECC.

FYI; It is also happening on Xeon E3v2 (Ivy Bridge generation) w/ 32GB 
of ECC RAM here, a low-end server part that officially supports up to 32GB.

> [    0.000000] microcode: microcode updated early to revision 0x20, date = 2018-04-10
> [    0.029728] L1TF: System has more than MAX_PA/2 memory. L1TF mitigation not effective.
> [    1.063155] microcode: sig=0x306a9, pf=0x2, revision=0x20


> processor	: 7
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 58
> model name	: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz
> stepping	: 9
> microcode	: 0x20
> cpu MHz		: 3500.044
> cache size	: 8192 KB
> physical id	: 0
> siblings	: 8
> core id		: 3
> cpu cores	: 4
> apicid		: 7
> initial apicid	: 7
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 13
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d
> bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
> bogomips	: 6602.15
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 36 bits physical, 48 bits virtual
> power management:


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ