On Mon, Mar 16, 2015 at 03:08:40PM -0700, Kees Cook wrote: > > > >> Ok I think I am finally seeing where you are going. And I like it *a > >> lot* because it allows us to basically replace mmap_sem with rcu > >> (MMF_EXE_FILE_CHANGED being the only user that requires a lock!!), but > >> am afraid it might not be possible. I mean currently we have no rule wrt > >> to users that don't deal with prctl. > >> > >> Forbidding multiple exe_file changes to be generic would certainly > >> change address space semantics, probably for the better (tighter around > >> security), but changed nonetheless so users would have a right to > >> complain, no? So if we can get away with removing MMF_EXE_FILE_CHANGED > >> I'm all for it. Andrew? > > I can't figure out why MMF_EXE_FILE_CHANGED is used to stop a second > change. But it does seem useful to mark a process as "hey, we know for > sure this the exe_file changed on this process" from an accounting > perspective. Sure, except it start being more stopper for further development so ripping it off would help ;) > > And I'd agree about the malware: it would never use this interface, so > there's no security benefit I can see. Maybe I haven't had enough > coffee, though. :) Yes, same here, would never use it either. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>