linux-kernel - Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

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: <nycvar.YFH.7.76.1807260102300.997@cbobk.fhfr.pm>
Date:   Thu, 26 Jul 2018 01:11:01 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Borislav Petkov <bp@...e.de>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Peter Zijlstra <peterz@...radead.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH] x86/bugs: protect against userspace-userspace
 spectreRSB

On Wed, 25 Jul 2018, Linus Torvalds wrote:

> > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > context switch when generic spectrev2 mitigation has been enabled.
> 
> Shouldn't this also do something like
> 
>      x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP;
> 
> if we have HT enabled?

So IIUC your comment is not really tightly related to spectreRSB, is it?

If you're making a more general remark about things that we'd also have to 
do in order to improve userspace-userspace spectrev2 prevention, then I 
agree.

It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I 
think though, as the VM switching also has to save/restore it properly 
(the same way we handle SSBD). So I'd rather handle this separately, as it 
really is in principle a completely different protection.

STIBP is plugging much smaller hole than spectreRSB (as the bigger part is 
already plugged by IBPB), so I'd rather have that one in first, and look 
at improving STIBP later if noone beats me to it.

Thanks,

-- 
Jiri Kosina
SUSE Labs