On Wed, May 11, 2022 at 8:58 AM Florian Weimer <fwei...@redhat.com> wrote: > > * H. J. Lu: > > > On Wed, May 11, 2022 at 1:12 AM Florian Weimer <fwei...@redhat.com> wrote: > >> > >> * H. J. Lu via Gcc-patches: > >> > >> > When -fcf-protection=branch is used, the compiler will generate jump > >> > tables where the indirect jump is prefixed with the NOTRACK prefix, so > >> > it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the > >> > NOTRACK specific enable bit must be set, what renders the binary broken > >> > on any environment where this is not the case. In fact, having NOTRACK > >> > disabled was a design choice for the Linux kernel CET support. > >> > >> Why isn't that a kernel bug? It doesn't match what is in the current > >> glibc sources. > > > > User space uses NOTRACK in the jump table in assembly codes. > > And is expected to continue to use it?
Yes, it should be allowed in user space. > >> > Generate jump tables with ENDBR and skip the NOTRACK prefix for indirect > >> > jump. Document -mno-cet-switch to turn off CET instrumentation on jump > >> > tables for switch statements. > >> > >> Of course, that is a slight regression in security hardening. > >> > >> Quite frankly, I'm puzzled why the kernel decided to require these > >> additional ENDBR instructions. > > > > Kernel is using -mcet-switch today. Should we document -mcet-switch > > and keep it off by default instead? > > Sorry, I'm not 100% certain of the mechanics/options involved. > > I think the default should reflect userspace requirements, like with the > red zone and vector register usage for integer code. The question is if the compiler should use NOTRACK by default for the jump table. It is independent of whether NOTRACK is enabled or not. Should I check in my patch asis? Thanks. -- H.J.
