linux-kernel - Removing MAX_ARG_PAGES (request for comments/assistance)

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

Message-ID: <65dd6fd50610101705t3db93a72sc0847cd120aa05d3@mail.gmail.com>
Date:	Tue, 10 Oct 2006 17:05:09 -0700
From:	"Ollie Wild" <aaw@...gle.com>
To:	linux-kernel@...r.kernel.org, parisc-linux@...ts.parisc-linux.org
Cc:	"Linus Torvalds" <torvalds@...l.org>,
	"Arjan van de Ven" <arjan@...radead.org>,
	"Ingo Molnar" <mingo@...e.hu>, linux-mm@...ck.org,
	"Andrew Morton" <akpm@...l.org>, "Andi Kleen" <ak@....de>,
	linux-arch@...r.kernel.org, "David Howells" <dhowells@...hat.com>
Subject: Removing MAX_ARG_PAGES (request for comments/assistance)

Hi,

A few months back, there was some discussion about increasing
MAX_ARG_PAGES (http://thread.gmane.org/gmane.linux.kernel/418858).
Since this is a problem which Google seems to bump into on a regular
basis -- we just keep jacking up the limit -- I thought I'd have  a
stab at implementing the preferred solution as outlined by Linus.

I've attached a patch which replaces the pages array from the
linux_binprm struct with a stack vm_area added to the new process's
mm_struct.  The region grows using the normal page fault / stack
extension mechanism.  Since the vm_area is swappable -- which I've
confirmed via testing -- we don't have to worry about memory
starvation.

I've tested this on the um/i386, i386, and x86_64 architectures with
the elf and script binfmts.  I'd like to get feedback from the Linux
community.  If anyone would like to test/implement the areas I've
missed, I'd greatly appreciate it.

Some outstanding issues / concerns:

- I haven't addressed the CONFIG_STACK_GROWSUP (parisc) case.  Would
someone on the parisc list be willing to have a go at this?  Grant
Grundler has offered to provide me access to hardware, but I'd prefer
to let a pa-risc guru have a go.

- I haven't tested this on a NOMMU architecture.  Could someone please
validate this?

- What, if any command line limits should we enforce?  The do_execve()
callchain has plenty of hooks where the calling process can sleep, so
CPU starvation shouldn't be a problem.  Memory consumption is limited
by the RLIMIT_STACK setting.  Note, however, that I'm not providing
any guarantee on the availability of space for the actual stack.

- Inside setup_arg_pages(), I have to move the stack region.
Different linux_binfmt handlers place it in different locations
relative to STACK_TOP, and STACK_TOP itself may have different values
depending on the personality of the executable.  When executing
scripts, the arg strings need to be accessed before we know which
binary format is being executed, so we can't generally make the
correct determination beforehand.

- There are  bunch of linux_binfmt handlers which are either obsolete
or specific to particular platforms.  Would someone be willing to look
at these?

Thanks,
Ollie

View attachment "no_MAX_ARG_PAGES.patch" of type "text/x-patch" (26707 bytes)