linux-kernel - Re: [RFC PATCH 0/1] support ftrace and -ffunction-sections

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: <20181127210942.4067ad46@vmware.local.home>
Date:   Tue, 27 Nov 2018 21:09:42 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joe Lawrence <joe.lawrence@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Subject: Re: [RFC PATCH 0/1] support ftrace and -ffunction-sections

On Tue, 27 Nov 2018 15:27:14 -0500
Joe Lawrence <joe.lawrence@...hat.com> wrote:

> Gentle ping...  I took a dive through the rhkl-archives and found a few
> older discussions:

Thanks for the reminder, my INBOX is totally out of control with
Plumbers followed by Turkey Day.

> 
>   [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections.
>   https://lore.kernel.org/lkml/CAFbHwiRtBaHkpZqTm6VZ=fCJcyu+dsdpo_kxMHy1egce=rTuyA@mail.gmail.com/
> 
> and related LWN article:
> 
>   The source of the e1000e corruption bug
>   https://lwn.net/Articles/304105/
> 
> Catching up with those, I assume that this has never been implemented in
> the past due to fear of ftrace modifying a potentially freed section
> (and bricking NICs in the process :(

Actually, we have a lot more safe guards against that today.

> 
> Looking through the kernel sources (like Will in 2008) I don't see any
> code jumping out at me that frees code other than .init.  However a
> quick code inspection is no guarantee.
> 
> Assuming the same use-after-free reservation holds true today:
> 
>   1: Is there any reasonable way to mark code sections (pages?) as
>      in-use to avoid memory freeing mechanisms from releasing them?  The
>      logic for .init is mostly arch-specific, so there could be many 
>      different ways random arches may try to pull this off.
> 
>   2: Would/could it be safer to restrict __mcount_loc detection of
>      ".text.*" sections to modules?  The recordmcount.pl script already
>      knows about is_module... that information could be provided to
>      recordmcount.c as well for consideration.

I'm fine with just applying your patch. Today, for x86, there's a gcc
option that adds the __mcount_loc automatically without doing any
whitelisting (it doesn't run recordmcount.*). It just adds anything that
is traced, thus it has to work for all possible cases now.

-- Steve