On Wed, May 11, 2022 at 9:03 PM Florian Weimer via Gcc-patches
<[email protected]> wrote:
>
> * H. J. Lu:
>
> > On Wed, May 11, 2022 at 11:45 AM Florian Weimer <[email protected]> wrote:
> >>
> >> * H. J. Lu:
> >>
> >> >> NOTRACK avoids the need for ENDBR instructions, right? That's a
> >> >> hardening improvement, so it should be used by default.
> >> >
> >> > NOTRACK weakens IBT since it disables IBT on the indirect jump
> >> > instruction.
> >> > GCC uses it in the jump table to avoid ENDBR.
> >>
> >> Typical jump table code looks like this:
> >>
> >> Dump of assembler code for function __cache_sysconf:
> >> 0x00000000000f7a80 <+0>: endbr64
> >> 0x00000000000f7a84 <+4>: sub $0xb9,%edi
> >> 0x00000000000f7a8a <+10>: cmp $0xc,%edi
> >> 0x00000000000f7a8d <+13>: ja 0xf7b70 <__cache_sysconf+240>
> >> 0x00000000000f7a93 <+19>: lea 0xba926(%rip),%rdx # 0x1b23c0
> >> 0x00000000000f7a9a <+26>: movslq (%rdx,%rdi,4),%rax
> >> 0x00000000000f7a9e <+30>: add %rdx,%rax
> >> 0x00000000000f7aa1 <+33>: notrack jmp *%rax
> >>
> >> There's no ENDBR instruction between range check, the address
> >> computation, and the NOTRACK JMP, so it's not possible to redirect that
> >> JMP to some other place.
> >
> > That is the assumption we made. RAX will always point to the valid
> > address.
>
> Which means that NOTRACK should not weaken anything here. What am I
> missing?
Probably nothing. Still if the code computing the address to jump to
is exploitable
it might be useful. Like considering
void foo (int *idx) { switch (*idx) { ...; default:
__builtin_unreachable (); } }
then GCC would elide the range check for the jump table lookup.
I think the main reason for the NOTRACK is code size and the requirement to
place extra ENDBR at each jump target (where any ENDBR is a possible
valid target to use as gadget from a tracked brach).
So NOTRACK branches are bad and ENDBR are both "bad"?
Richard.
>
> Thanks,
> Florian
>
