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
| ||
|
Date: Tue, 5 Feb 2019 07:18:01 +0100 From: Borislav Petkov <bp@...en8.de> To: Dave Hansen <dave.hansen@...el.com> Cc: Thomas Gleixner <tglx@...utronix.de>, Fenghua Yu <fenghua.yu@...el.com>, Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>, Ashok Raj <ashok.raj@...el.com>, Peter Zijlstra <peterz@...radead.org>, Michael Chan <michael.chan@...adcom.com>, Ravi V Shankar <ravi.v.shankar@...el.com>, Ricardo Neri <ricardo.neri@...el.com>, linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org> Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote: > Actually, there's one part of all this that I forgot. Will split lock > detection be enumerated _widely_? You never know what users will do. The moment it gets out, it better be designed properly, along with the chicken bits. > IOW, will my laptop in 5 years enumerate support for it? Don't tell me this is going to be another MPX fiasco :-\ Or is this something along the lines of "let's see whether it takes off and if yes, we'll commit to it or otherwise remove it and not even waste a CPUID leaf"? > If so, we surely don't want to enable this everyhwhere: it will break > old apps. Doesn't that mean that we need both feature detection and > another separate bit for folks to opt-in? Well, if it breaks old apps, it probably needs to be opt-in anyway. And for that you don't need setcpuid either - you simply boot with "split_lock_ac" or whatever and the kernel pokes that MSR_TEST_CTL or whatever else it needs to detect in hw for split lock and sets the X86_FEATURE bits if detection is successful. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists