Messages in this thread | | | Date | Mon, 26 Mar 2007 15:37:30 +0300 (EEST) | From | Pekka J Enberg <> | Subject | Re: [PATCH -mm] Revoke core code: fix nommu arch compiling error bug |
| |
Hi,
Pekka J Enberg <penberg@cs.helsinki.fi> 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 <penberg@cs.helsinki.fi> 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 <penberg@cs.helsinki.fi> 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 <penberg@cs.helsinki.fi> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |