Hi, Pekka J Enberg <[EMAIL PROTECTED]> wrote: > > revoke_mapping() is mostly same as munmap(2) except that it preserves the > > vma but makes it VM_REVOKED. This means that if the process tries to > > access the region it will SIGBUS and if it tries to remap the range it > > will get EINVAL.
On Mon, 26 Mar 2007, David Howells wrote: > Yeah, that's not enforceable in NOMMU-mode situations. I presume it differs > from munmap() also in that it can effectively be forced by one process upon > another. Yes. On Mon, 26 Mar 2007, David Howells wrote: > In MMU-mode, how does this work with private mappings that have some private > copies of the pages that make up the mapping? Are those still available to a > process that is using them? Are they revoked when swapped out? Or are they > forcibly evicted? We don't touch private mappings at all as they're a snapshot to the inode _before_ it was revoked. So private mappings don't really matter all: you don't see any new data after it has been revoked nor do you flush anything to the disk. Pekka J Enberg <[EMAIL PROTECTED]> wrote: > > - If there are shared mappings, always return -ENOENT for revoke(2). On Mon, 26 Mar 2007, David Howells wrote: > That sounds feasible. How about -ETXTBSY instead? Well, assuming we would use revoke for things like SAK, this doesn't really work out too well because all a malicious process has to is create a shared mapping and they've effectively blocked the whole thing. Pekka J Enberg <[EMAIL PROTECTED]> wrote: > > - If there are shared mappings, immediately raise SIGBUS for those > > processes that are accessing it. On Mon, 26 Mar 2007, David Howells wrote: > Hmmm... maybe. That sounds a bit antisocial though, but is also > workable. It's antisocial for sure but the only way to guarantee revoke() succeeds on a NOMMU setup. Oh well, lets disable it for now and see if anyone even wants revoke() for NOMMU. Pekka J Enberg <[EMAIL PROTECTED]> wrote: > Does the SIGBUS raised have its own si_code, btw? Perhaps BUS_REVOKED? That's a good idea. I'll add one. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/