linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Jonathan Corbet <corbet@lwn.net>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Jiri Kosina <jikos@kernel.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	KarimAllah Ahmed <karahmed@amazon.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [RFC PATCH] x86/speculation: Don't inherit TIF_SSBD on execve()
Date: Wed, 19 Dec 2018 14:45:07 -0500	[thread overview]
Message-ID: <f2cd45e2-e390-a6f6-f4fb-1d316be0f54c@redhat.com> (raw)
In-Reply-To: <20181219193822.GU25620@tassilo.jf.intel.com>

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



  reply	other threads:[~2018-12-19 19:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-19 19:09 [RFC PATCH] x86/speculation: Don't inherit TIF_SSBD on execve() Waiman Long
2018-12-19 19:38 ` Andi Kleen
2018-12-19 19:45   ` Waiman Long [this message]
2018-12-20  0:58     ` Andi Kleen
2019-01-07 14:49 ` Waiman Long
2019-01-11 19:52 ` Thomas Gleixner
2019-01-14 21:46   ` Waiman Long
2019-01-15  9:48     ` Thomas Gleixner
2019-01-15 15:54       ` Waiman Long

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2cd45e2-e390-a6f6-f4fb-1d316be0f54c@redhat.com \
    --to=longman@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dwmw@amazon.co.uk \
    --cc=hpa@zytor.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=karahmed@amazon.de \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).