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: > a) Fix the application to map the memory +x > b) Add some code to glibc to map the memory +x when sigaltstack is called. > c) Add some (parisc-only) code to kernel to set the permission. 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. Helge
