linux-kernel - Re: Avoid speculative indirect calls in kernel

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: <20180104174045.GH13348@redhat.com>
Date:   Thu, 4 Jan 2018 18:40:45 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "pavel@....cz" <pavel@....cz>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "andi@...stfloor.org" <andi@...stfloor.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>
Subject: Re: Avoid speculative indirect calls in kernel

Hi Alan,

On Thu, Jan 04, 2018 at 05:04:42PM +0000, Alan Cox wrote:
> > If you run lots of syscalls ibrs 1 ibpb 1 is much faster. If you do
> > infrequent syscalls computing a lot in kernel like I/O with large
> > buffers getting copied, ibrs 0 ibpb 2 is much faster than ibrs 1 ibpb
> > 1 (on those microcodes where ibrs 1 reduces performance a lot, not all
> > microcodes implementing SPEC_CTRL are inefficient like that).
> 
> Have you looked at whether you can measure activity and switch
> automatically between the two (or by task). It seems silly to leave
> something the machine can accurately assess toa human ?

We didn't but it'd be definitely reasonable to investigate and it's a
good idea for those CPUs where the updated microcode has to shutdown
way more than just indirect branch prediction speculation to achieve
the ibrs 1 semantics.

If the workload changes from frequent syscalls to reasonably large
read/writes and less frequent syscalls or lots of interrupts in idle
CPUs, it would work well to switch between ibrs 1 ibpb 1 and ibpb 2
ibrs 0 automatically. As long as the pattern keeps repeating for a
while... that is the question ;).

Thanks!
Andrea