On Tue, Oct 2, 2012 at 2:41 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxx> wrote: > 2012/10/2 Kees Cook <keescook@xxxxxxxxxxxx>: >>> If desired, additional restrictions can be imposed by using the >>> security framework, e.g,, disallow non-final r-x mappings. >> >> Interesting; what kind of interface did you have in mind? > > The 'interface' we use is a LSM .ko which registers handlers for > mmap() and mprotect() that fail the respective invocations if the > passed arguments do not adhere to the policy. Seems reasonable. >>>> It seems like there needs to be a sensible way to detect that this flag is >>>> available, though. >>> >>> I am open for suggestions to address this. Our particular >>> implementation of the loader (on an embedded system) tries to set it >>> on the first mmap invocation, and stops trying if it fails. Not the >>> most elegant approach, I know ... >> >> Actually, that seems easiest. >> >> Has there been any more progress on this patch over-all? > > No progress. Al, Andrew, anyone? Thoughts on this? (First email is https://lkml.org/lkml/2012/8/14/448) -Kees -- Kees Cook Chrome OS Security -- 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>