Re: CET/IBT support and live-patches

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Nov 23, 2021 at 12:39:15PM +0100, Miroslav Benes wrote:

> 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.