linux-kernel - Re: [RFC PATCH] x86/speculation: Don't inherit TIF

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 Dec 2018 14:45:07 -0500
From:   Waiman Long <longman@...hat.com>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Jonathan Corbet <corbet@....net>, x86@...nel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Jiri Kosina <jikos@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        KarimAllah Ahmed <karahmed@...zon.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [RFC PATCH] x86/speculation: Don't inherit TIF_SSBD on execve()

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