linux-kernel - Re: [PATCH] FDPIC: Ignore the loader's PT_GNU

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]

Message-ID: <8bd0f97a0907140515t2bc47674qac75ba93f8c9fdae@mail.gmail.com>
Date:	Tue, 14 Jul 2009 08:15:03 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	David Howells <dhowells@...hat.com>, rgetz@...ckfin.uclinux.org,
	lethal@...ux-sh.org, gerg@...inux.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating 
	the stack size

On Sat, Jul 11, 2009 at 17:30, Pavel Machek wrote:
> On Thu 2009-07-09 11:59:11, David Howells wrote:
>> Pavel Machek wrote:
>> > > i really dont think this is realistic.  there is exactly one ldso that
>> > > everyone uses under FDPIC ELF, and it needs a very minuscule stack.
>> >
>> > Not very realistic; but that argues that the patch is NOP.
>> >
>> > And if it _is_ realistic, the patch adds a bug.
>>
>> No, it doesn't.  The problem is that the loader, when it is linked, is given a
>> sillyly large default stack size, and this causes the application to be given a
>> much larger stack than is strictly necessary - a stack that is drawn from a
>> limited pool of non-pageable RAM and that must be allocated as a contiguous
>> lump.
>
> Fix the loader to only request as big stack as it needs?

and what if the loader needs a larger stack when run as an application
?  you could make the same exact argument for every library that an
application has a DT_NEEDED tag for, or that it dlopen()'s.  but for
the same reasons, it doesnt fly.

the only stack that should be checked is what the application itself
says it needs.  the ldso has no way of knowing what functions exactly
the application in question will be using (whether in the ldso itself
or in any library), thus only the application itself knows what the
stack usage will look like.
-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/