> -----Original Message----- > From: Jiri Kosina [mailto:[email protected]] > Sent: Monday, September 10, 2018 12:14 PM > To: Schaufler, Casey <[email protected]> > Cc: Thomas Gleixner <[email protected]>; Ingo Molnar <[email protected]>; > Peter Zijlstra <[email protected]>; Josh Poimboeuf > <[email protected]>; Andrea Arcangeli <[email protected]>; > Woodhouse, David <[email protected]>; Andi Kleen <[email protected]>; > Tim Chen <[email protected]>; [email protected]; > [email protected] > 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
