Re: [RFC PATCH v2 13/13] objtool: arm64: Enable stack validation for arm64

[Julien Thierry]

On 3/7/21 11:25 AM, Ard Biesheuvel wrote:
> On Wed, 3 Mar 2021 at 18:10, Julien Thierry <jthierry@xxxxxxxxxx> wrote:
> > From: Raphael Gault <raphael.gault@xxxxxxx>
> >
> > Add build option to run stack validation at compile time.
> >
> > When requiring stack validation, jump tables are disabled as it
> > simplifies objtool analysis (without having to introduce unreliable
> > artifacs). In local testing, this does not appear to significaly
> > affect final binary size nor system performance.
> >
> > Signed-off-by: Raphael Gault <raphael.gault@xxxxxxx>
> > Signed-off-by: Julien Thierry <jthierry@xxxxxxxxxx>
> > ---
> >   arch/arm64/Kconfig  | 1 +
> >   arch/arm64/Makefile | 4 ++++
> >   2 files changed, 5 insertions(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 1f212b47a48a..928323c03318 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -187,6 +187,7 @@ config ARM64
> >          select MMU_GATHER_RCU_TABLE_FREE
> >          select HAVE_RSEQ
> >          select HAVE_STACKPROTECTOR
> > +       select HAVE_STACK_VALIDATION
> >          select HAVE_SYSCALL_TRACEPOINTS
> >          select HAVE_KPROBES
> >          select HAVE_KRETPROBES
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 5b84aec31ed3..b819fb2e8eda 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -136,6 +136,10 @@ ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y)
> >     CC_FLAGS_FTRACE := -fpatchable-function-entry=2
> >   endif
> >
> > +ifeq ($(CONFIG_STACK_VALIDATION),y)
> > +KBUILD_CFLAGS  += -fno-jump-tables
> > +endif
> > +
>
> This is a bit misleading: the Kconfig option in question is selected
> automatically in all cases, so jump tables are always disabled.

So, at the moment, the arch Kconfig only advertises that arm64 has stack 
validation with objtool, but currently stack validation itself is not 
enabled by default.

> However, I think disabling jump tables make sense anyway, at least
> when building the relocatable kernel for KASLR: we currently don't use
> -fpic/fpie in that case when building the vmlinux objects (because we
> don't want/need GOT tables), and so jump tables are emitted using
> absolute addresses, which induce some space overhead in the image. (24
> bytes of RELA data per absolute address)
>
> ... unless I am missing something, and jump tables can/will be emitted
> as relative, even when not compiling in PIC mode?

Personally I don't have enough context to assess whether it's the way to 
go. But if nobody opposes I'm fine having -fno-jump-tables in the 
default arm64 CFLAGS.

Thanks,

--
Julien Thierry