On Tue, 27 Nov 2018 15:27:14 -0500 Joe Lawrence <[email protected]> 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=rt...@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
