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 > <rick.p.edgecombe@xxxxxxxxx> wrote: > > > > On Fri, 2023-03-10 at 12:00 -0800, H.J. Lu wrote: > > > > > 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.
