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]

Date:	Mon, 26 Mar 2007 14:55:29 +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

On Mon, 26 Mar 2007, David Howells wrote:
> I don't know, what does it do?  Remember, once a NOMMU process thinks it has
> the right to access a mapping, there's no way of stopping it doing so short of
> killing the process.

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.

What we're trying to do here is, we want to make sure no other tasks can 
access the inode once it has been revoked.

On Mon, 26 Mar 2007, David Howells wrote:
> With NOMMU as it stands, private mappings are private copies of the data, and
> have no impact on the page cache and get no updates from it.  It's as if you
> took a private writable mapping, touched every page and then mprotect()'d it.
> This isn't necessarily ideal, but we're limited by the lack on an MMU.

So there's no way to raise SIGBUS if the range is being accessed. The 
alternatives are:

  - No support for revoke(2) on NOMMU.
  - If there are shared mappings, always return -ENOENT for revoke(2).
  - If there are shared mappings, immediately raise SIGBUS for those 
    processes that are accessing it.

Making the shared mappings private is not an option because there's no way 
for the process to know that it's mapping is being pulled under it which 
will result in bugs. Hmm.

				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/