Re: [PATCH] posix_spawn: use a larger min stack for -fstack-check [BZ #21253]

[Andrew Pinski <pinskia at gmail dot com>]

On Thu, Mar 16, 2017 at 2:52 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 16 Mar 2017 09:17, Florian Weimer wrote:
>> On 03/16/2017 08:30 AM, Mike Frysinger wrote:
>> > When glibc is built with -fstack-check, trying to use posix_spawn can
>> > lead to segfaults due to gcc internally probing stack memory too far.
>> > The new spawn API will allocate a minimum of 1 page, but the stack
>> > checking logic might probe a couple of pages.  When it tries to walk
>> > them, everything falls apart.
>> >
>> > The gcc internal docs [1] state the default interval checking is one
>> > page.  Which means we need two pages (the current one, and the next
>> > probed).  No target currently defines it larger.
>>
>> GCC miscomputes the offsets in some cases, so I would not rely on this.
>>
>> Would it be possible compile the functions involved without
>> -fstack-check instead?
>
> i mentioned in the bug that it's not feasible: compiling this one file
> doesn't help as it calls other glibc funcs which will have checking
> enabled.  so we'd have to manually track the full call stack here and
> disable it on all the files which is a fairly fragile/burdensome process.
>
>> >    /* Add a slack area for child's stack.  */
>> >    size_t argv_size = (argc * sizeof (void *)) + 512;
>> > -  size_t stack_size = ALIGN_UP (argv_size, GLRO(dl_pagesize));
>> > +  /* We need at least a few pages in case the compiler's stack checking is
>> > +     enabled.  In some configs, it is known to use at least 24KiB.  */
>> > +  size_t stack_size = ALIGN_UP (argv_size, 32 * 1024);
>>
>> 64 KiB pages are common, so this reduces the stack size in many cases.
>
> common where ?  are you talking about large pages ?
>
> going by PAGE_SHIFT in the kernel, looks to me like very few
> targets allow using 64 KiB at all, let alone being common.

RHEL on ARM64 defaults to 64k.
For Cavium Octeon SDK, the mips kernel defaults to 64k page size.

Thanks,
Andrew

>
> alpha: 8 KiB
> arc: kconfig allows 4, 8 (default), or 16 KiB
> arm: 4 KiB
> arm64: kconfig allows 4, 16, or 64 KiB (default depends on # of VMA bits)
> avr32: 4 KiB
> cris: 8 KiB
> frv: 16 KiB
> hexagon: kconfig allows 4 (default), 16, 64, 256 KiB, or 1 MiB
> ia64: kconfig allows 4, 8, 16 (default), or 64 KiB
> m32r: 4 KiB
> m68k: 4 (non-coldfire) or 8 KiB (coldfire)
> meta: kconfig allows 4 (default), 8, or 16 KiB
> microblaze: kconfig allows 4 (default), 16, or 64 KiB
> mips: kconfig allows 4 (default for most, but gets tricky), 8, 16, 32, or 64 KiB
> mn10300: 4 KiB
> nios2: 4 KiB
> openrisc: 8 KiB
> parisc: kconfig allows 4 (default), 16, or 64 KiB
> powerpc: kconfig allows 4 (default), 16, 64, or 256 KiB
> s390: 4 KiB
> score: 4 KiB
> sh: 4 KiB (for no-mmu, you have other choices)
> sparc32: 4 KiB
> sparc64: 8 KiB
> tile: kconfig allows 4, 16, or 64 KiB (default)
> unicore32: 4 KiB
> x86: 4 KiB
> xtensa: 4 KiB
>
> i picked 32 KiB as a trade off of it being more than big enough and
> being a nice multiple of 4, 8, and 16, while not overtly allocating
> too much otherwise unused.
> -mike