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

[Pekka J Enberg]

Hi,

Pekka J Enberg <penberg@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/