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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.21.1809112302580.1427@nanos.tec.linutronix.de>
Date:   Tue, 11 Sep 2018 23:15:25 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Schaufler, Casey" <casey.schaufler@...el.com>
cc:     Jiri Kosina <jikos@...nel.org>, 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:
> > -----Original Message-----
> > From: Jiri Kosina [mailto:jikos@...nel.org]
> > Sent: Monday, September 10, 2018 1:42 PM
> > 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;
> > x86@...nel.org

Casey, can you please spare us the completely redundant copy of the mail
header?

> 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.

I'm not yet convinced that making these decisions purely based on LSM is a
good idea. The LSM based decision can optionally replace the built in
default decision at runtime, but it cannot replace it because its simpler
for most people to install a new kernel than fiddling with LSM.

We want a halfways sane default solution for this ASAP and Jiri's patch is
straight forward providing one without preventing you from adding your
magic LSM stuff once you have time to work on it including all (locking)
problems it creates. Nice try to offload that to Jiri.

Thanks,

	tglx