On Mon, 2018-06-18 at 14:44 -0700, Andy Lutomirski wrote:

On Sat, Jun 16, 2018 at 8:16 PM Balbir Singh [off-list ref] wrote:

quoted

On Thu, 2018-06-14 at 07:56 -0700, Yu-cheng Yu wrote:

quoted

On Thu, 2018-06-14 at 11:07 +1000, Balbir Singh wrote:

quoted

On Tue, 2018-06-12 at 08:03 -0700, Yu-cheng Yu wrote:

quoted

On Tue, 2018-06-12 at 20:56 +1000, Balbir Singh wrote:

quoted

On 08/06/18 00:37, Yu-cheng Yu wrote:

quoted

This series introduces CET - Shadow stack

At the high level, shadow stack is:

      Allocated from a task's address space with vm_flags VM_SHSTK;
      Its PTEs must be read-only and dirty;
      Fixed sized, but the default size can be changed by sys admin.

For a forked child, the shadow stack is duplicated when the next
shadow stack access takes place.

For a pthread child, a new shadow stack is allocated.

The signal handler uses the same shadow stack as the main program.

Even with sigaltstack()?

Yes.

I am not convinced that it would work, as we switch stacks, oveflow might
be an issue. I also forgot to bring up setcontext(2), I presume those
will get new shadow stacks

Do you mean signal stack/sigaltstack overflow or swapcontext in a signal
handler?

I meant any combination of that. If there is a user space threads implementation that uses sigaltstack for switching threads

Anyone who does that is nuts.  The whole point of user space threads
is speed, and signals are very slow.  For userspace threads to work,
we need an API to allocate new shadow stacks, and we need to use the
extremely awkwardly defined RSTORSSP stuff to switch.  (I assume this
is possible on an ISA level.  The docs are bad, and the mnemonics for
the relevant instructions are nonsensical.)

The whole point was to ensure we don't break applications/code that work
today. I think as long as there is a shadow stack allocated corresponding
to the user space stack and we can Restore SSP as we switch things should be
fine.

Balbir Singh.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html