linux-kernel - Re: [RFC][POWERPC] Provide a way to protect 4k subpages when using 64k pages

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] [day] [month] [year] [list]

Message-Id: <1197416288.8385.21.camel@pasglop>
Date:	Wed, 12 Dec 2007 10:38:08 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Christoph Hellwig <hch@....de>
Cc:	Paul Mackerras <paulus@...ba.org>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][POWERPC] Provide a way to protect 4k subpages when using
	64k pages

On Tue, 2007-12-11 at 16:53 +0100, Christoph Hellwig wrote:
> All these process would use plain mmap/
> mprotect to deal with the subpage protections.

That seems very hard to do ... all of the generic code here only knows
about the base page size, so except if we're going to fully re-implement
the mmap/mprotect logic from scratch, it's going to hurt, or am I
missing something ?

I suppose we could add wrappers to those syscalls that always set the
protection map to "no access" over the target area (from within
get_unmapped_area for mmap as we don't know the area yet), and then,
update it after the successful call.

But mprotect seems a clumsy way to control the per-sub-page permission
in that case as we don't want to change the underlying real 64k page
permission.

Ben.

--
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/