linux-kernel - Re: [Patch v4 17/18] x86/speculation: Update SPEC

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:   Mon, 5 Nov 2018 15:59:37 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Kees Cook <keescook@...omium.org>
Subject: Re: [Patch v4 17/18] x86/speculation: Update SPEC_CTRL MSRs of remote
 CPUs

Thomas,

> 
> 
> Aside of the condition being pointless in that case, that issues an IPI
> whether the task is running or not. So this allows a task to issue tons of
> async IPIs disturbing others by toggling the control.

I'm not crazy about sending IPIs too.  Hence the original implementation
using TIF_UPDATE_SPEC_CTRL flag.

I've thought a bit about the options you suggested and was unclear
on a few things.

> 1) Restrict the PRCTL control so it is only possible to modify it at the
>    point where the application is still single threaded.
>

My understanding is PRCTL applied on the task only. Should it be extended
to other task threads?  In that case, it seems like we didn't do that for SSBD?

> 2) Add _TIF_UPDATE_SPEC_CTRL to the SYSCALL_EXIT_WORK_FLAGS and handle it
>    in the slow work path.

There can be tasks that don't do any syscalls, and it seems like we can have MSRs getting
out of sync?

> 
> I'm less and less convinced that piggybacking this on dumpable is a good
> idea. 

There are daemons like sshd that are non-dumpable.  So I think protecting
them is desired.  Otherwise all those daemons will need to be updated to
use PRCTL.  In the original implementation, IBPB is issued for
non-dumpable task.  It will be nice to retain that.

Thanks.

Tim