linux-kernel - Re: [RFC][PATCH] x86: ptrace: Add function argument access API

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: <20181017223447.0cdcd422@vmware.local.home>
Date:   Wed, 17 Oct 2018 22:34:47 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RFC][PATCH] x86: ptrace: Add function argument access API

On Mon, 15 Oct 2018 23:56:46 +0900
Masami Hiramatsu <mhiramat@...nel.org> wrote:

> On Fri, 12 Oct 2018 15:54:39 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > On Fri, 12 Oct 2018 11:21:28 -0700
> > Andy Lutomirski <luto@...capital.net> wrote:
> >   
> > > On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt <rostedt@...dmis.org> wrote:  
> > > >
> > > >
> > > > Anyone have any issues with this patch?
> > > >    
> > > 
> > > I'm conceptually okay with it.  That being said,
> > > regs_within_kernel_stack(), which you're indirectly using, is
> > > off-by-a-few.  And updating it to use probe_kernel_read() might be
> > > nice for robustness.
> > >   
> > 
> > Something like this?
> > 
> > -- Steve
> > 
> > From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
> > Date: Fri, 12 Oct 2018 15:44:20 -0400
> > Subject: [PATCH] x86: ptrace.h: Add regs_get_kernel_stack_nth_safe() function
> > 
> > Andy had some concerns about using regs_get_kernel_stack_nth() in a new
> > function regs_get_kernel_argument() as if there's any error in the stack
> > code, it could cause a bad memory access. Instead, add a new function called
> > regs_get_kernel_stack_nth_safe() that does a probe_kernel_read() on the
> > stack address to be extra careful in accessing the memory. To share the
> > code, regs_get_kernel_stack_nth_addr() was added to just return the stack
> > address (or NULL if not on the stack), that both regs_get_kernel_stack_nth()
> > and the _safe() version can use.  
> 
> This patch looks good to me.
> But if the concern is real, all regs_get_kernel_stack_nth() user must move
> onto _safe() version, at least all tracers code.
> 
> Reviewed-by: Masami Hiramatsu <mhiramat@...nel.org>
> 

Hi Masami,

Can you review my v2 version which implements what you suggest.

Thanks,

-- Steve