On Fri, 2023-03-10 at 12:43 -0800, H.J. Lu wrote:

On Fri, Mar 10, 2023 at 12:27 PM Edgecombe, Rick P
[off-list ref] wrote:

quoted

On Fri, 2023-03-10 at 12:00 -0800, H.J. Lu wrote:

quoted

quoted

quoted

So it does:
1. Enable shadow stack
2. Call elf libs checking functions
3. If all good, lock shadow stack. Else, disable shadow
stack.
4. Return from elf checking functions and if shstk is
enabled,
don't
underflow because it was enabled in step 1 and we have return
addresses
from 2 on the shadow stack

I'm wondering if this can't be improved in glibc to look
like:
1. Check elf libs, and record it somewhere
2. Wait until just the right spot
3. If all good, enable and lock shadow stack.

I will try it out.

Currently glibc enables shadow stack as early as possible.  There
are only a few places where a function call in glibc never
returns.
We can enable shadow stack just before calling main.   There are
quite some code paths without shadow stack protection.   Is this
an issue?

Thanks for checking. Hmm, does the loader get attacked?

Not I know of.  But there are user codes from .init_array
and .preinit_array which are executed before main.   In theory,
an attack can happen before main.

Hmm, it would be nice to not add any startup overhead to non-shadow
stack binaries. I guess it's a tradeoff. Might be worth asking around.

But you can't just enable shadow stack before any user code? It has to
go something like?
1. Execute init codes
2. Check elf libs
3. Enable SHSTK

Or what if you just did the enable-disable dance if the execing binary
itself has shadow stack. If it doesn't have shadow stack, the elf libs
won't change the decision.