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

[Thomas Gleixner]

On Mon, 10 Sep 2018, Schaufler, Casey wrote:
> > -----Original Message-----
> > From: Jiri Kosina [mailto:jikos@xxxxxxxxxx]
> > Sent: Monday, September 10, 2018 1:42 PM
> > To: Schaufler, Casey <casey.schaufler@xxxxxxxxx>
> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>;
> > Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Josh Poimboeuf
> > <jpoimboe@xxxxxxxxxx>; Andrea Arcangeli <aarcange@xxxxxxxxxx>;
> > Woodhouse, David <dwmw@xxxxxxxxxxxx>; Andi Kleen <ak@xxxxxxxxxxxxxxx>;
> > Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> > x86@xxxxxxxxxx

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