> -----Original Message----- > From: Jiri Kosina [mailto:ji...@kernel.org] > Sent: Monday, September 10, 2018 12:14 PM > To: Schaufler, Casey <casey.schauf...@intel.com> > Cc: Thomas Gleixner <t...@linutronix.de>; Ingo Molnar <mi...@redhat.com>; > Peter Zijlstra <pet...@infradead.org>; Josh Poimboeuf > <jpoim...@redhat.com>; Andrea Arcangeli <aarca...@redhat.com>; > Woodhouse, David <d...@amazon.co.uk>; Andi Kleen <a...@linux.intel.com>; > Tim Chen <tim.c.c...@linux.intel.com>; linux-kernel@vger.kernel.org; > x...@kernel.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: > > > Why are you dropping the LSM check here, when in v4 you fixed the > > SELinux audit locking issue? We can avoid introducing an LSM hook > > and all the baggage around it if you can do the > security_ptrace_access_check() > > here. > > So what guarantees that none of the hooks that > security_ptrace_access_check() is invoking will not be taking locks (from > scheduler context in this case)?
The locking issue in the security modules is the same regardless of whether the call of security_ptrace_access_check() comes from the __ptrace_access_check() you're adding here or from a new security hook (I have proposed security_task_safe_sidechannel) that gets added in the same place later on. Adding a new hook results in duplication, because there now has to be code that does exactly the same thing as __ptrace_access_check() but without the new NOACCESS_CHECK mode. Yes, It would require that this patch be tested against all the existing security modules that provide a ptrace_access_check hook. It's not like the security module writers don't have a bunch of locking issues to deal with. > Thanks, > > -- > Jiri Kosina > SUSE Labs
