lkml.org 
[lkml]   [2007]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-03-26 14:41    [W:0.112 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site