This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/maps tomake stack executable


> Using __libc_stack_end as the end of stack to mark an executable stack
> misses pages at the end of stack that are used to store program
> arguments, environment variables and auxiliary elf information.

This actually seems desireable to me.  If there are additional whole pages
of arguments et al, those pages don't need to be executable, so why make
them so?

> Due to this, the stack vma gets split and later requests for stack
> address using pthread_getattr_np() return a different value than before.

Perhaps it should work in a different way.  It's nasty to require /proc
access, and all the io plus stdio overhead et al might make it more costly
than another method.  It could use something like the mprotect-probing
technique to locate the hole below the stack that linux/dl-execstack.c uses
when PROT_GROWSDOWN is not available.

Conversely, the existing /proc/self/maps mechanism could just be adjusted
in one of two ways.

1. Just cache the past results and apply them as upper/lower bounds so that
   you never return a smaller size later.

2. Treat contiguous mappings below the stack all as part of the stack.

> +static void
> +get_main_stack_bounds (void **from, void **to)
> +{
> +  FILE *proc = fopen ("/proc/self/maps", "r");
> +  char *l = NULL;
> +  size_t size;
> +  while (getline (&l, &size, proc) != -1)
> +    {
> +      sscanf (l, "%p-%p", from, to);
> +      if (strstr (l, "[stack]"))
> +	return;
> +    }
> +
> +  /* There should at least be one [stack].  */
> +  abort ();
> +}

This is unconditionally adding Linux-specific code to the test, which
is not acceptable.  It also fails to check the return value of sscanf,
and should use '!= NULL' rather than implicit boolean coercion.

Why test at this level, anyway?  The bug is that the execstack switch
makes pthread_getattr_np give inconsistent results.  So just test that
pthread_getattr_np gives the same results before and after the switch.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]