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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 9 Oct 2017 09:31:24 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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, Oct 9, 2017 at 9:21 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 9 Oct 2017 08:33:51 -0700
> Joel Fernandes <joelaf@...gle.com> wrote:
>>
>> 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.

Yes, this is what I am doing in the next revision.

> 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?

Yes in case of allocation failure, WARN_ONCE would seem reasonable to
me for this case.

thanks,

- Joel