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:	Sun, 10 May 2009 14:45:33 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>, hannes@...xchg.org,
	riel@...hat.com, linux-kernel@...r.kernel.org, tytso@....edu,
	linux-mm@...ck.org, elladan@...imo.com, npiggin@...e.de,
	cl@...ux-foundation.org, minchan.kim@...il.com
Subject: Re: [PATCH -mm] vmscan: make mapped executable pages the first
 class  citizen

On Sun, 10 May 2009 18:36:19 +0900
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> wrote:
> I don't oppose this policy. PROT_EXEC seems good viewpoint.

I don't think it is that simple

Not only can it be abused but some systems such as java have large
PROT_EXEC mapped environments, as do many other JIT based languages.

Secondly it moves the pressure from the storage volume holding the system
binaries and libraries to the swap device which already has to deal with
a lot of random (and thus expensive) I/O, as well as the users filestore
for mapped objects there - which may even be on a USB thumbdrive.

I still think the focus is on the wrong thing. We shouldn't be trying to
micro-optimise page replacement guesswork - we should be macro-optimising
the resulting I/O performance. My disks each do 50MBytes/second and even with the
Gnome developers finest creations that ought to be enough if the rest of
the system was working properly.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ