Re: CET/IBT support and live-patches
From: Peter Zijlstra <peterz@infradead.org>
Date: 2021-11-23 14:11:00
On Tue, Nov 23, 2021 at 12:39:15PM +0100, Miroslav Benes wrote:
quoted hunk ↗ jump to hunk
Ok. And we would need something like the following for the livepatch (not even compile tested). ---diff --git a/arch/powerpc/include/asm/livepatch.h b/arch/powerpc/include/asm/livepatch.h index 4fe018cc207b..7b9dcd51af32 100644 --- a/arch/powerpc/include/asm/livepatch.h +++ b/arch/powerpc/include/asm/livepatch.h@@ -19,16 +19,6 @@ static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip) regs_set_return_ip(regs, ip); } -#define klp_get_ftrace_location klp_get_ftrace_location -static inline unsigned long klp_get_ftrace_location(unsigned long faddr) -{ - /* - * Live patch works only with -mprofile-kernel on PPC. In this case, - * the ftrace location is always within the first 16 bytes. - */ - return ftrace_location_range(faddr, faddr + 16); -} - static inline void klp_init_thread_info(struct task_struct *p) { /* + 1 to account for STACK_END_MAGIC */diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c index fe316c021d73..81cd9235e160 100644 --- a/kernel/livepatch/patch.c +++ b/kernel/livepatch/patch.c@@ -127,15 +127,18 @@ static void notrace klp_ftrace_handler(unsigned long ip, /* * Convert a function address into the appropriate ftrace location. * - * Usually this is just the address of the function, but on some architectures - * it's more complicated so allow them to provide a custom behaviour. + * Usually this is just the address of the function, but there are some + * exceptions. + * + * * PPC - live patch works only with -mprofile-kernel. In this case, + * the ftrace location is always within the first 16 bytes. + * * x86_64 with CET/IBT enabled - there is ENDBR instruction at +0 offset. + * __fentry__ follows it. */ -#ifndef klp_get_ftrace_location -static unsigned long klp_get_ftrace_location(unsigned long faddr) +static inline unsigned long klp_get_ftrace_location(unsigned long faddr) { - return faddr; + return ftrace_location_range(faddr, faddr + 16); } -#endif
Agreed, in fact, it should have called at least ftrace_location() before, as a sanity check the address is in fact a listed fentry site. I wonder though, given ftrace_cmp_recs() what the behaviour is if there's two fentry sites within those 16 bytes... I don't think it will uniquely return the leftmost one, so that might need some thinking. Consider: foo: endbr call __fentry__ ret; bar: endbr call __fentry__ ... then both sites are within 16 bytes of one another.