Thread (9 messages) 9 messages, 3 authors, 2019-01-15

Re: [RFC PATCH] x86/speculation: Don't inherit TIF_SSBD on execve()

From: Waiman Long <longman@redhat.com>
Date: 2018-12-19 19:45:15
Also in: lkml

On 12/19/2018 02:38 PM, Andi Kleen wrote:
On Wed, Dec 19, 2018 at 02:09:50PM -0500, Waiman Long wrote:
quoted
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.

The arch_setup_new_exec() function is updated to clear the TIF_SSBD
bit unless it has been force-disabled.
This makes it impossible to write a wrapper that turns this mode
on for unmodified programs.
You can always force disable SSB. In that case, all the child processes
will have SSBD on.
Do you have a real use case where this behavior is a problem?

-Andi
Yes, we have an enterprise application partner that found that their
application slow down up to 10-20% depending on how their application
was set up. With the slow setup, the application was spawned by Java
processes causing the SSBD bit to stay on when the application was running.

Cheers,
Longman

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help