linux-kernel - Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up return probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d2e0e53581e26358ee0b3d188a07795878938d2f.camel@intel.com>
Date: Fri, 3 May 2024 20:35:24 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "olsajiri@...il.com" <olsajiri@...il.com>
CC: "songliubraving@...com" <songliubraving@...com>, "luto@...nel.org"
	<luto@...nel.org>, "mhiramat@...nel.org" <mhiramat@...nel.org>,
	"andrii@...nel.org" <andrii@...nel.org>, "debug@...osinc.com"
	<debug@...osinc.com>, "john.fastabend@...il.com" <john.fastabend@...il.com>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>, "rostedt@...dmis.org"
	<rostedt@...dmis.org>, "ast@...nel.org" <ast@...nel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "linux-man@...r.kernel.org"
	<linux-man@...r.kernel.org>, "oleg@...hat.com" <oleg@...hat.com>,
	"yhs@...com" <yhs@...com>, "daniel@...earbox.net" <daniel@...earbox.net>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"bp@...en8.de" <bp@...en8.de>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, "broonie@...nel.org" <broonie@...nel.org>
Subject: Re: [PATCHv4 bpf-next 2/7] uprobe: Add uretprobe syscall to speed up
 return probe

On Fri, 2024-05-03 at 22:17 +0200, Jiri Olsa wrote:
> when uretprobe is created, kernel overwrites the return address on user
> stack to point to user space trampoline, so the setup is in kernel hands

I mean for uprobes in general. I'm didn't have any specific ideas in mind, but
in general when we give the kernel more abilities around shadow stack we have to
think if attackers could use it to work around shadow stack protections.

> 
> with the hack below on top of this patchset I'm no longer seeing shadow
> stack app crash on uretprobe.. I'll try to polish it and send out next
> week, any suggestions are welcome ;-)

Thanks. Some comments below.

> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/arch/x86/include/asm/shstk.h b/arch/x86/include/asm/shstk.h
> index 42fee8959df7..d374305a6851 100644
> --- a/arch/x86/include/asm/shstk.h
> +++ b/arch/x86/include/asm/shstk.h
> @@ -21,6 +21,8 @@ unsigned long shstk_alloc_thread_stack(struct task_struct
> *p, unsigned long clon
>  void shstk_free(struct task_struct *p);
>  int setup_signal_shadow_stack(struct ksignal *ksig);
>  int restore_signal_shadow_stack(void);
> +void uprobe_change_stack(unsigned long addr);
> +void uprobe_push_stack(unsigned long addr);

Maybe name them:
shstk_update_last_frame();
shstk_push_frame();


>  #else
>  static inline long shstk_prctl(struct task_struct *task, int option,
>                                unsigned long arg2) { return -EINVAL; }
> diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
> index 59e15dd8d0f8..804c446231d9 100644
> --- a/arch/x86/kernel/shstk.c
> +++ b/arch/x86/kernel/shstk.c
> @@ -577,3 +577,24 @@ long shstk_prctl(struct task_struct *task, int option,
> unsigned long arg2)
>                 return wrss_control(true);
>         return -EINVAL;
>  }
> +
> +void uprobe_change_stack(unsigned long addr)
> +{
> +       unsigned long ssp;

Probably want something like:

	if (!features_enabled(ARCH_SHSTK_SHSTK))
		return;

So this doesn't try the below if shadow stack is disabled.

> +
> +       ssp = get_user_shstk_addr();
> +       write_user_shstk_64((u64 __user *)ssp, (u64)addr);
> +}

Can we know that there was a valid return address just before this point on the
stack? Or could it be a sigframe or something?

> +
> +void uprobe_push_stack(unsigned long addr)
> +{
> +       unsigned long ssp;

	if (!features_enabled(ARCH_SHSTK_SHSTK))
		return;

> +
> +       ssp = get_user_shstk_addr();
> +       ssp -= SS_FRAME_SIZE;
> +       write_user_shstk_64((u64 __user *)ssp, (u64)addr);
> +
> +       fpregs_lock_and_load();
> +       wrmsrl(MSR_IA32_PL3_SSP, ssp);
> +       fpregs_unlock();
> +}
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index 81e6ee95784d..259457838020 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -416,6 +416,7 @@ SYSCALL_DEFINE0(uretprobe)
>         regs->r11 = regs->flags;
>         regs->cx  = regs->ip;
>  
> +       uprobe_push_stack(r11_cx_ax[2]);

I'm concerned this could be used to push arbitrary frames to the shadow stack.
Couldn't an attacker do a jump to the point that calls this syscall? Maybe this
is what peterz was raising.

>         return regs->ax;
>  
>  sigill:
> @@ -1191,8 +1192,10 @@ arch_uretprobe_hijack_return_addr(unsigned long
> trampoline_vaddr, struct pt_regs
>                 return orig_ret_vaddr;
>  
>         nleft = copy_to_user((void __user *)regs->sp, &trampoline_vaddr,
> rasize);
> -       if (likely(!nleft))
> +       if (likely(!nleft)) {
> +               uprobe_change_stack(trampoline_vaddr);
>                 return orig_ret_vaddr;
> +       }
>  
>         if (nleft != rasize) {
>                 pr_err("return address clobbered: pid=%d, %%sp=%#lx,
> %%ip=%#lx\n",