Re: glibc tst-minsigstksz-5 failure

[Sven Schnelle <svens@stackframe.org>]

John David Anglin <dave.anglin@bell.net> writes:

> On 2021-12-08 8:05 a.m., Helge Deller wrote:
>> On 12/8/21 13:51, Helge Deller wrote:
>>> On 12/7/21 22:47, John David Anglin wrote:
>>>> The glibc tst-minsigstksz-5 test fails with a protection id trap.
>>>> tst-minsigstksz (pid 19958): Protection id trap (code 7) at 00000000f5b00497
>>>>
>>>> The problem seems to be that the signal return trampoline is placed
>>>> on the alternate stack but the alternate is not executable.  It is
>>>> allocated by malloc.> ...
>>>> Stacks are normally executable on hppa so the trampoline works.  But
>>>> user code wouldn't normally make an alternate stack executable.
>>> True, I think most people just forget that such architectures exist.
>>>
>>> Anyway, the glibc testcase is interesting.
>>> The pretty similar sigaltstack testcase from LTP does work:
>>> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/sigaltstack/sigaltstack01.c
>>>
>>> Both use malloc() to allocate the memory, the only difference is the size allocated.
>>> If you change the glibc testcase to:
>>> -- size_t stack_buffer_size = 64 * 1024 * 1024;
>>> ++ size_t stack_buffer_size = SIGSTKSZ;
>>> it allocates only 8kB instead of 64MB.
>>> It seems glibc uses brk() in both cases, but when allocating 64MB it additionally adds a mmap() with READ/WRITE permissions only:
>>> brk(0x606000)                           = 0x606000
>>> mmap2(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf303f000
>>>
>>> This will then break - as you mentioned - the signal handling on parisc.
>>>
>>> I see those options to fix it:/usr/include/hppa-linux-gnu/asm/signal.h:#define MINSIGSTKSZ    2048
> I wonder about defining MINSIGSTKSZ to 2048 as it is smaller than a page.
>
> mprotect requires a page aligned address.  Alternate stack isn't going to be page aligned if it is allocated by
> malloc.  Malloc alignment isn't sufficient for nominal 64-byte stack alignment specified in runtime.
>>> /usr/include/hppa-linux-gnu/asm/signal.h:#define SIGSTKSZ       8192
>>>
>>> a) Fix the application to map the memory +x
> Doesn't fix problem..
>>> b) Add some code to glibc to map the memory +x when sigaltstack is called.
> See mprotect comment.
>>> c) Add some (parisc-only) code to kernel to set the permission.
> Again, I think region needs to be page aligned.
>> Option d):
>> Enhance the kernel to create a per-process new page and map it +rx into the userspace
>> at process start time. Kernel sets up the page to contain the signal trampoline code.
>>
>> Option e):
>> Finally implement vDSO, which then includes option d)
>>
>> With options d) and e) we could get completely rid of executable stacks.
> I like the later two options.

Note that programs are allowed to unmap the vdso. Valgrind is doing that (guess it
doesn't support hppa anyways). OTOH valgrind uses SA_RESTORER, so it
would still work. While i don't think the possibility of unmapping the
vdso would be a real issue, i thought i mention it.

Regards
Sven