linux-kernel - RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

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 for Android: free password hash cracker in your pocket

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

Message-ID: <nycvar.YFH.7.76.1809102332290.15880@cbobk.fhfr.pm>
Date:   Mon, 10 Sep 2018 23:36:00 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     "Schaufler, Casey" <casey.schaufler@...el.com>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to
 avoid cross-process data leak

On Mon, 10 Sep 2018, Schaufler, Casey wrote:

> > So please tell me what exactly you'd like to see changed in the IBPB patch
> > and why exactly, I am not seeing it yet.
> 
> Short of a patch to show the changes (which I wish I could do today, but really can't)
> what I want to see is:
> 
> 	- Put ptrace back to using the security module interfaces.
> 	- Identify where this causes locking issues and work with the module
> 	  owners (a reasonable lot, all) to provide lock safe paths for the IBPB case.
> 
> Otherwise, I have to add a new LSM hook right after your ptrace call and duplicate
> a whole lot of what you've just turned off, plus creating lock safe code that duplicates
> what ptrace already does. While I would rather have the side-channel checks be
> separate from the ptrace checks I can't justify doing both.

So why can't this be then done as 2nd step, once you've audited the LSM 
callbacks and worked around the locking in LSM callbacks/audit code?

Once that is taken care of, of course feel free to undo the changes my 
patch is doing so that you don't have to duplicate any ptrace code.

But before all that is fixed / worked around in LSM/audit (and I don't 
have spare cycles for doing that myself), why not take the simple aproach 
for now?

Thanks,

-- 
Jiri Kosina
SUSE Labs