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: Thu, 18 Oct 2018 15:53:46 +0200 (CEST) From: Thomas Gleixner <tglx@...utronix.de> To: Tim Chen <tim.c.chen@...ux.intel.com> cc: Jiri Kosina <jikos@...nel.org>, Tom Lendacky <thomas.lendacky@....com>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Andrea Arcangeli <aarcange@...hat.com>, David Woodhouse <dwmw@...zon.co.uk>, Andi Kleen <ak@...ux.intel.com>, Dave Hansen <dave.hansen@...el.com>, Casey Schaufler <casey.schaufler@...el.com>, Asit Mallick <asit.k.mallick@...el.com>, Arjan van de Ven <arjan@...ux.intel.com>, Jon Masters <jcm@...hat.com>, linux-kernel@...r.kernel.org, x86@...nel.org Subject: Re: [Patch v3 10/13] x86/speculation: Add per thread STIBP flag On Wed, 17 Oct 2018, Tim Chen wrote: Again the subject is misleading, It's suggesting that it adds a per thread flag. But the patch does way more than that. > Add per thread STIBP flag. When context switching to a process thread that > has the STIBP flag, the STIBP bit in the SPEC_CTRL MSR will be turned > on to guard against application to application Spectre v2 attack. When > switching to a non-security sensitive thread that doesn't have STIBP flag, > the STIBP bit in the SPEC_CTRL MSR is turned off. I think I gave you quite some examples how such a changelog should look like. > --- a/arch/x86/include/asm/thread_info.h > +++ b/arch/x86/include/asm/thread_info.h > @@ -83,6 +83,7 @@ struct thread_info { > #define TIF_SYSCALL_EMU 6 /* syscall emulation active */ > #define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */ > #define TIF_SECCOMP 8 /* secure computing */ > +#define TIF_STIBP 9 /* Single threaded indirect branch predict */ > #define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */ > #define TIF_UPROBE 12 /* breakpointed or singlestepping */ > #define TIF_PATCH_PENDING 13 /* pending live patching update */ > @@ -110,6 +111,7 @@ struct thread_info { > #define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU) > #define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT) > #define _TIF_SECCOMP (1 << TIF_SECCOMP) > +#define _TIF_STIBP (1 << TIF_STIBP) > #define _TIF_USER_RETURN_NOTIFY (1 << TIF_USER_RETURN_NOTIFY) > #define _TIF_UPROBE (1 << TIF_UPROBE) > #define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING) > @@ -146,7 +148,8 @@ struct thread_info { > > /* flags to check in __switch_to() */ > #define _TIF_WORK_CTXSW \ > - (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD) > + (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \ > + _TIF_SSBD|_TIF_STIBP) These flags are at random locations. I wonder whether they should be grouped together. Might not influence code generation, but at least worth to have a look. > + /* > + * Need STIBP defense against Spectre v2 attack > + * if SMT is in use and we don't have enhanced IBRS. and enhanced IBRS is not supported. > + */ > + if (static_branch_likely(&cpu_smt_enabled) && > + !static_branch_unlikely(&spectre_v2_enhanced_ibrs)) > + msr |= stibp_tif_to_spec_ctrl(tifn); > + > wrmsrl(MSR_IA32_SPEC_CTRL, msr); > } Thanks, tglx
Powered by blists - more mailing lists