On Tue, Sep 04, 2018 at 07:35:29PM +0200, Jiri Kosina wrote: > On Tue, 4 Sep 2018, Tim Chen wrote: > > > > Current ptrace_may_access() implementation assumes that the 'source' task > > > is > > > always the caller (current). > > > > > > Expose ___ptrace_may_access() that can be used to apply the check on > > > arbitrary > > > tasks. > > > > Casey recently has proposed putting the decision making of whether to > > do IBPB in the security module. > > > > https://lwn.net/ml/kernel-hardening/20180815235355.14908-4-casey.schauf...@intel.com/ > > > > That will have the advantage of giving the administrator a more flexibility > > of when to turn on IBPB. The policy is very similar to what you have > > proposed here > > but I think the security module is a more appropriate place for the > > security policy. > > Yeah, well, honestly, I have a bit hard time buying the "generic > sidechannel prevention security module" idea, given how completely > different in nature all the mitigations have been so far. I don't see that > trying to abstract this somehow provides more clarity. > > So if this should be done in LSM, it'd probably have to be written by > someone else than me :) who actually understands how the "sidechannel LSM" > idea works.
Yeah, I'm not convinced on LSM either. Lets just do these here patches first and then Casey can try and convince us later.
