Re: [PATCH -mm] Revoke core code: fix nommu arch compiling error bug

Pekka J Enberg
2007-03-26T12:37:34Z

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