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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0703261525370.14158@sbz-30.cs.Helsinki.FI>
Date:	Mon, 26 Mar 2007 15:37:30 +0300 (EEST)
From:	Pekka J Enberg <penberg@...helsinki.fi>
To:	David Howells <dhowells@...hat.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>, bryan.wu@...log.com,
	linux-kernel@...r.kernel.org, Hugh Dickins <hugh@...itas.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH -mm] Revoke core code: fix nommu arch compiling error
 bug

Hi,

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