On Thu, 2018-11-22 at 08:53 -0800, Andy Lutomirski wrote: > [cc some more libc folks] > > I have a general question about this patch set: > > If I'm writing a user program, and I write a signal handler, there are > two things I want to make sure I can still do: > > 1. I want to be able to unwind directly from the signal handler > without involving sigreturn() -- that is, I want to make sure that > siglongjmp() works. How does this work? Is INCSSP involved? How Yes, siglongjmp() works by doing INCSSP. > exactly does the user program know how much to increment SSP by? (And > why on Earth does INCSSP only consider the low 8 bits of its argument? > That sounds like a mistake. Can Intel still fix that? On the other GLIBC calculates how many frames to be unwound and breaks into 255 batches when necessary. > hand, what happens if you INCSSP off the end of the shadow stack > entirely? I assume the next access will fault as long as there's an > appropriate guard page.) Yes, that is the case. > > 2. I want to be able to modify the signal context from a signal > handler such that, when the signal handler returns, it will return to > a frame higher up on the call stack than where the signal started and > to a different RIP value. How can I do this? I guess I can modify > the shadow stack with WRSS if WR_SHSTK_EN=1, but how do I tell the > kernel to kindly skip the frames I want to skip when I do sigreturn()? > > The reason I'm asking #2 is that I think it's time to resurrect my old > vDSO syscall cancellation helper series here: > > https://lwn.net/Articles/679434/ If tools/testing/selftests/x86/unwind_vdso.c passes, can we say the kernel does the right thing? Or do you have other tests that I can run? > > and it's not at all clear to me that __vdso_abort_pending_syscall() > can work without kernel assistance when CET is enabled. I want to > make sure that it can be done, or I want to come up with some other > way to allow a signal handler to abort a syscall while CET is on. I > could probably change __vdso_abort_pending_syscall() to instead point > RIP to __kernel_vsyscall's epilogue so that we con't change the depth > of the call stack. But I could imagine that other user programs might > engage in similar shenanigans and want to have some way to unwind a > signal's return context without actually jumping there a la > siglongjmp(). > > Also, what is the intended setting of WR_SHSTK_EN with this patch set applied? This bit enables WRSS instruction, which writes to kernel SHSTK. This patch set uses only WRUSS and WR_SHSTK_EN is not be set. > > (I suppose we could just say that 32-bit processes should not use CET, > but that seems a bit sad.) They work in compat mode. Should anything break, we can fix it. Yu-cheng
