| Message ID | 20210303170932.1838634-14-jthierry@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | objtool: add base support for arm64 | expand |
On Wed, 3 Mar 2021 at 18:10, Julien Thierry <jthierry@redhat.com> wrote: > > From: Raphael Gault <raphael.gault@arm.com> > > 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@arm.com> > Signed-off-by: Julien Thierry <jthierry@redhat.com> > --- > 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. 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? > # Default value > head-y := arch/arm64/kernel/head.o > > -- > 2.25.4 >
On 3/7/21 11:25 AM, Ard Biesheuvel wrote: > On Wed, 3 Mar 2021 at 18:10, Julien Thierry <jthierry@redhat.com> wrote: >> >> From: Raphael Gault <raphael.gault@arm.com> >> >> 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@arm.com> >> Signed-off-by: Julien Thierry <jthierry@redhat.com> >> --- >> 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,
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 + # Default value head-y := arch/arm64/kernel/head.o