linux-kernel - Re: [PATCH] x86/ftrace: Don't bother preserving/restoring R10/R11

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: <20241009123153.4a26f226@gandalf.local.home>
Date: Wed, 9 Oct 2024 12:31:53 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>,
 linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org, Masami
 Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH] x86/ftrace: Don't bother preserving/restoring R10/R11

On Wed, 9 Oct 2024 18:25:25 +0200
Ard Biesheuvel <ardb@...nel.org> wrote:

> > Say we have code of:
> >
> >         pushq   r10
> >         pushq   r11
> >         call    foo
> >         popq    r11
> >         popq    r10
> >
> > Where we add a kprobe to the start of foo, the callback should be able to
> > see what r10 and r11 were.  
> 
> Why exactly is that? The contents of R10 and R11 have no purpose going
> forward, so is it just to see what some previous code may have left in
> them?

Because the probe is on the call. Unless they were used between the push
and the call, they still have the value you may be looking for.

> 
> > But the restore part is for the function foo to
> > see. It shouldn't care about r10 or r11 and if a kprobe updates them, it
> > should not have any effect.
> >
> > What does restoring r10 and r11 give us?
> >  
> 
> Nothing. Which is why I don't understand why you would need to record
> them in the first place.

As I mentioned above. Unless they are used after they are pushed, you still
have access to them on the call (or the kprobe attached to ftrace).

-- Steve