Jeff Xu <jeffxu@xxxxxxxxxx> wrote: > In linux cases, I think, eventually, mseal() will have a bigger scope than > BSD's mimmutable(). I don't believe that, considering noone needed this behaviour from the VM system in the last 4 decades. > VMA's metadata(vm_area_struct) contains a lot > of control info, depending on application's needs, mseal() can be > expanded to seal individual control info. > For example, in madvice(2) case: > As Jann point out in [1] and I quote: > "you'd probably also want to block destructive madvise() operations > that can effectively alter region contents by discarding pages and > such, ..." Then prohibit madvise(MADV_FREE) on all non-writeable mappings that are immutable. Just include this in the set of behaviours. Or make it the default. Don't make it an option that a program needs to set on pages! Noone is going to call it. Most programs don't know the addresses of the *REGIONS* they would want to do this for. Does your program know where libc's text segment starts and ends? No your program does not know these addresses, so the parts of the 'system' which do know this needs to do it (which would be ld.so or the libc init constructors). If madvise(MADV_FREE) is so dangerous.. say you have a program that would call through abort(), but you know a zero there can make the abort not abort but return, then is it bad to let the attacker do: madvise(&abort, pagesize, MADV_FREE) If that is bad, then block it in a smart way! Don't make a programmer of an application figure out how to do this. That results in a defense methodology where a handful of programs self-protect, but everything else is unprotected or unprotectable. That is shortsighted. > Another example: if an application wants to keep a memory always > present in RAM, for whatever the reason, it can call seal the mlock(). Please explain the attack surface. > I think I explained the logic of using bitmasks in the mseal() > interface clearly with the example of madvice() and mlock(). It is clear as mud.
