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