[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1809121401080.9957@nanos.tec.linutronix.de>
Date: Wed, 12 Sep 2018 14:01:27 +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 Tue, 11 Sep 2018, Schaufler, Casey wrote:
> How about this? Take Jiri's patch as written. You get everything except checks
> on the security blobs and any "magic" that my safesidechannel module did. I
> will propose a follow on patch that fixes the SELinux code to eliminate the locking
> issue and enables the LSM hooks in the IBPB case. I can then do a revised "magic"
> safesidechannel security module that uses the ptrace hook instead of adding a
> new hook explicitly for IBPB. There is some danger that in the future ptrace and
> IBPB criteria will diverge sufficiently that a common hook becomes nonsensical.
> As no one else seems concerned about this possibility, I won't lose any sleep over
> it either.
Sounds like a plan.
Powered by blists - more mailing lists