[PATCH] tst-setcontext10.c: Undef _FORTIFY_SOURCE

[H.J. Lu]

On Wed, Dec 20, 2023 at 4:54 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Dec 19, 2023 at 11:57 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * H. J. Lu:
> >
> > > void ____longjmp_chk (__jmp_buf env, int val)
> > > {
> > >   void *this_frame = __builtin_frame_address (0);
> > >   void *saved_frame = JB_FRAME_ADDRESS (env);
> > >   stack_t ss;
> > >
> > >   /* If "env" is from a frame that called us, we're all set.  */
> > >   if (called_from(this_frame, saved_frame))  <<< This is false for user context
> > >     __longjmp (env, val);
> >
> > Why isn't this a problem without shadow stack?
>
> It is a problem without shadow stack:
>
> https://sourceware.org/pipermail/libc-alpha/2023-December/153409.html
>
> > But what I meant was: Do the longjmp checks really add value over the
> > checking that shadow stack longjmp inevitably does?
> >
>
> No, I don't think so.  But IFUNC can't be used since shadow stack may
> be enabled after IFUNC resolver has been initialized.

____longjmp_chk checks:

static jmp_buf b;

static void
__attribute__ ((noinline))
f (void)
{
  char buf[1000];
  asm volatile ("" : "=m" (buf));

  if (setjmp (b) != 0)
    {
      puts ("second longjmp succeeded");
      exit (1);
    }
}

void
b (void)
{
  f ();
  longjmp (b, 1);
}

Shadow stack doesn't prevent it.


H.J.

-- 
H.J.