linux-kernel - Re: [RFC PATCH] x86/speculation: Add finer control for when to issue IBPB

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]

Message-ID: <20210113102536.GC16960@zn.tnic>
Date:   Wed, 13 Jan 2021 11:25:36 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Anand K Mistry <amistry@...gle.com>
Cc:     x86@...nel.org, asteinhauser@...gle.com, tglx@...utronix.de,
        joelaf@...gle.com, Anand K Mistry <amistry@...omium.org>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Julien Thierry <jthierry@...hat.com>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Mike Rapoport <rppt@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tony Luck <tony.luck@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] x86/speculation: Add finer control for when to issue
 IBPB

On Wed, Jan 13, 2021 at 07:47:19PM +1100, Anand K Mistry wrote:
> When IB speculation is conditionally disabled for a process (via prctl()
> or seccomp), IBPB is issued whenever that process is switched to/from.
> However, this results more IBPBs than necessary. The goal is to protect
> a victim process from an attacker poisoning the BTB by issuing IBPB in
> the attacker->victim switch. However, the current logic will also issue
> IBPB in the victim->attacker switch, because there's no notion of
> whether the attacker or victim has IB speculation disabled.
> 
> Instead of always issuing IBPB when either the previous or next process
> has IB speculation disabled, add a boot flag to explicitly choose
> to issue IBPB when the IB spec disabled process is entered or left.
> 
> Signed-off-by: Anand K Mistry <amistry@...gle.com>
> Signed-off-by: Anand K Mistry <amistry@...omium.org>

Two SoBs by you, why?

> ---
> Background:
> IBPB is slow on some CPUs.
> 
> More detailed background:
> On some CPUs, issuing an IBPB can cause the address space switch to be
> 10x more expensive (yes, 10x, not 10%).

Which CPUs are those?!

> On a system that makes heavy use of processes, this can cause a very
> significant performance hit.

You're not really trying to convince reviewers for why you need to add
more complexity to an already too complex and confusing code. "some
CPUs" and "can cause" is not good enough.

> I understand this is likely to be very contentious. Obviously, this
> isn't ready for code review, but I'm hoping to get some thoughts on the
> problem and this approach.

Yes, in the absence of hard performance data, I'm not convinced at all.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette