On Wed, Jan 10, 2018 at 11:50:46AM -0800, Linus Torvalds wrote: > And the whole "NOW" vs "NEXT" is complete garbage. The obvious sane > no-PTI interface is that it > > (a) inherits on fork/exec, so that you don't have to worry about how > something is implemented (think "I want to run this kernel build > without the PTI overhead", but also "I want to run this system daemon > without PTI"). > > (b) actual domain changes clear it (ie suid, whatever). > > that make it useful for random uses of "I trust service XYZ".
OK. Do you want to see something *only* based on a wrapper (i.e. works only after execve) or can we let the application apply the change to itself ? I would also like to let applications re-enable the protection for processes they're going to exec and not necessarily trust. > So I'm NAK'ing this whole series on the grounds that it has several > completely insane semantics and really need to be clarified, and where > actual usage needs to be thought about a lot more. In fact we were trying to limit the risk of propagating the protection removal too far, and leave it only on the sensitive process which really requires it. But your example of "running the kernel build without PTI" makes sense from a user's perspective, and it completely contradicts our initial assumptions. After all I don't think the NOW vs NEXT is so fundamentally broken. We could think about having one option for the current process only (which is cleared by execve) so that applications can apply it to themselves only without having to wonder about clearing it, and another one which is only for wrappers and which passes execve(). For now I considered that we could stop at the first execve, but if I just remove the clearing of the NEXT flag, it matches your requirement for the kernel build. After this it's just a matter of naming and placing them on the mm rather than thread. Willy