linux-kernel - Re: [PATCH 3/3 v7] livepatch: Use the default ftrace_ops instead of REGS when ARGS is available

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] [day] [month] [year] [list]

Message-ID: <X7aYVgRa5uP8sAMM@alley>
Date:   Thu, 19 Nov 2020 17:07:50 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     linux-kernel@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org
Subject: Re: [PATCH 3/3 v7] livepatch: Use the default ftrace_ops instead of
 REGS when ARGS is available

On Thu 2020-11-19 09:12:35, Steven Rostedt wrote:
> On Thu, 19 Nov 2020 12:52:00 +0100
> Petr Mladek <pmladek@...e.com> wrote:
> 
> > >  #ifdef CONFIG_LIVEPATCH
> > > -static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
> > > +static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip)
> > >  {
> > > +	struct pt_regs *regs = ftrace_get_regs(fregs);  
> > 
> > Should we check for NULL pointer here?
> 
> As mentioned in my last email. regs could have been NULL for the same
> reasons before this patch, and we didn't check it then. Why should we check
> it now?
> 
> The ftrace_get_regs() only makes sure that a ftrace_ops that set
> FL_SAVE_REGS gets it, and those that did not, don't.
> 
> But that's not entirely true either. If there's two callbacks to the same
> function, and one has FL_SAVE_REGS set, they both can have access to the
> regs (before and after this patch). It's just that the one that did not
> have FL_SAVE_REGS set, isn't guaranteed to have it.

Makes sense. Thanks for explanation. Feel free to use:

Acked-by: Petr Mladek <pmladek@...e.com>

I actually did review of all patches and they looked fine to me.
I just did not check all corner cases, assembly, and did not test
it, so I give it just my ack. I believe your testing ;-)

Best Regards,
Petr