On Mon, 14 Jan 2019, Waiman Long wrote: > On 01/11/2019 02:52 PM, Thomas Gleixner wrote: > > On Wed, 19 Dec 2018, Waiman Long wrote: > > > >> With the default SPEC_STORE_BYPASS_SECCOMP/SPEC_STORE_BYPASS_PRCTL mode, > >> the TIF_SSBD bit will be inherited when a new task is fork'ed or cloned. > >> > >> As only certain class of applications (like Java) requires disabling > >> speculative store bypass for security purpose, it may not make sense to > >> allow the TIF_SSBD bit to be inherited across execve() boundary where the > >> new application may not need SSBD at all and is probably not aware that > >> SSBD may have been turned on. This may cause an unnecessary performance > >> loss of up to 20% in some cases. > > Lot's of MAY's here. Aside of that this fundamentally changes the > > behaviour. I'm not really a fan of doing that. > > > > If there are good reasons to have a non-inherited variant, then we rather > > introduce that instead of changing the existing semantics without a way for > > existing userspace to notice. > > I understand your point. How about adding a ",noexec" auxillary option > to the spec_store_bypass_disable command line to activate this new > behavior without changing the default. Will that be acceptable? I'd rather have an explicit PR_SPEC_DISABLE_NOEXEC argument for the PRCTL so you can decide at the application level what kind of behaviour you want. Thanks, tglx
