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]

Date:	Thu, 09 Jul 2009 11:59:11 +0100
From:	David Howells <dhowells@...hat.com>
To:	Pavel Machek <pavel@....cz>
Cc:	dhowells@...hat.com, Mike Frysinger <vapier.adi@...il.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

Pavel Machek <pavel@....cz> 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.

The executables should take into account the amount of stack space needed to
call into all their libraries - and that includes the loader.  You can argue
that the loader should specify the amount of extra overhead it will need, and
that this should be _added_ to the executable's stack estimate, but using the
loader's stack estimate instead of the executable's does not really make sense.

You can also argue that the executable doesn't know how much space the loader
will use, because the loader can be independently replaced; but this isn't a
good argument because the loader doesn't know how much the executable will use,
and neither know how much the various shared libs will use.  The only way to do
that is to add up all the stack estimates.

Now, it *is* perfectly reasonable to use the loader's stack estimate in the
case that the loader is run as an executable.  It could, for example, behave as
the GLIBC loader and have some functions available for shared library query and
suchlike.

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