linux-kernel - Re: [PATCH 5/7] NOMMU: Avoiding duplicate icache flushes of shared maps

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, 14 Dec 2009 18:55:43 -0500
From:	Mike Frysinger <vapier.adi@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	lethal@...ux-sh.org, jie.zhang@...log.com, stefani@...bold.net,
	gerg@...pgear.com, uclinux-dev@...inux.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] NOMMU: Avoiding duplicate icache flushes of shared 
	maps

On Thu, Dec 10, 2009 at 08:58, David Howells wrote:
> From: Mike Frysinger <vapier.adi@...il.com>
>
> When working with FDPIC, there are many shared mappings of read-only code
> regions between applications (the C library, applet packages like busybox,
> etc.), but the current do_mmap_pgoff() function will issue an icache flush
> whenever a VMA is added to an MM instead of only doing it when the map is
> initially created.
>
> The flush can instead be done when a region is first mmapped PROT_EXEC.  Note
> that we may not rely on the first mapping of a region being executable - it's
> possible for it to be PROT_READ only, so we have to remember whether we've
> flushed the region or not, and then flush the entire region when a bit of it is
> made executable.
>
> However, this also affects the brk area.  That will no longer be executable.
> We can mprotect() it to PROT_EXEC on MPU-mode kernels, but for NOMMU mode
> kernels, when it increases the brk allocation, making sys_brk() flush the extra
> from the icache should suffice.  The brk area probably isn't used by NOMMU
> programs since the brk area can only use up the leavings from the stack
> allocation, where the stack allocation is larger than requested.

this works fine for me, thanks.
Signed-off-by: Mike Frysinger <vapier@...too.org>
-mike
--
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/