John David Anglin <dave.anglin@xxxxxxxx> 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
