linux-kernel - Re: [PATCH RFC] ftrace: Clear hashes of saved init functions

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20171009122155.44616f36@gandalf.local.home>
Date:   Mon, 9 Oct 2017 12:21:55 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, Jessica Yu <jeyu@...nel.org>
Subject: Re: [PATCH RFC] ftrace: Clear hashes of saved init functions

On Mon, 9 Oct 2017 08:33:51 -0700
Joel Fernandes <joelaf@...gle.com> wrote:

> Hi Steve,
> 
> On Mon, Oct 9, 2017 at 8:09 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> > On Sun,  8 Oct 2017 14:33:04 -0700
> > Joel Fernandes <joelaf@...gle.com> wrote:
> >  
> >>
> >>  static void
> >>  clear_mod_from_hash(struct ftrace_page *pg, struct ftrace_hash *hash)
> >>  {
> >> @@ -5771,12 +5807,24 @@ void ftrace_release_mod(struct module *mod)  
> >
> > This is too late. This should be done by ftrace_free_mem().
> >  
> 
> Ok, I agree with you. Initially I started to do it this way but the
> locking made it more complicated. I'll work on a patch that does it at
> free_mem time and send it out today.
> 

Yeah, I noticed that too. You may have to allocate pages to store what
is getting cleared. Of course that then begs the question, what do we
do when we fail to allocate? Perhaps just WARN_ONCE() and then let them
leak?

-- Steve