[PATCH v5][makedumpfile 0/9] btf/kallsyms based makedumpfile extension for mm page filtering

[Tao Liu]

Hi Krister,

I took some time to think about the data erase functions as we
discussed previously, and I have implemented one sample data eraser
based on the current v5 extension framework in [1]. According to my
test, this works well and has no conflict with the mm page filtering
extensions. With this, people can do data erasure as well as page
filtering in both 1st/2nd kernel as long as btf/kallsyms info is
accessiable.

As for btf/kallsyms support for makedumpfile.conf based erasure, I
forgot to mention there is one critical info missing compare with "-x
vmlinux" dwarfinfo, is the type of global variables, please see the
patch [2]. As far as I know, currently kernel hasn't enabled the btf's
ability of including global variable's types. E.g. symbol "init_task",
we can only know its address by lookup kallsyms, but btf have no
record if its type, because it is a global variable. If we create
makedumpfile.conf as follows:

[vmlinux]
erase init_task

It can work with no problem for "-x vmlinux" because dwarfinfo
contains all info. But it will fail to btf/kallsyms, for btf doesn't
know init_task's type is task_struct. However this is not a problem
for makedumpfile extensions, because when programming, we can cast it
as task_struct by "init_task = GET_KERN_SYM(init_task); task_list =
init_task + KERN_MEMBER_OFF(task_struct, tasks); ...",  but we cannot
do the same to makedumpfile.conf.

In summary, if we still want to use makedumpfile.conf for data
erasure, "-x vmlinux"'s dwarfinfo is unavoidable for now.

Thanks,
Tao Liu

[1]: https://lore.kernel.org/kexec/20260610234249.10993-2-ltao@redhat.com/
[2]: https://lore.kernel.org/all/20250207012045.2129841-3-stephen.s.brennan@oracle.com/

On Tue, Jun 2, 2026 at 4:49 PM Krister Johansen <kjlx at templeofstupid.com> wrote:
>
> Hi Tao,
>
> On Tue, Jun 02, 2026 at 03:04:12PM +1200, Tao Liu wrote:
> > On Tue, Jun 2, 2026 at 12:47 PM Krister Johansen
> > <kjlx at templeofstupid.com> wrote:
> > Thanks for your in-depth explanation, it's very helpful to me for
> > designing the data erasing function.
>
> Thanks for the great discussion.
>
> > > On Tue, Jun 02, 2026 at 11:12:05AM +1200, Tao Liu wrote:
> > > > On Sat, May 30, 2026 at 9:11 AM Krister Johansen
> > > I wondered about this, but for data-structures that are smaller than a
> > > page, wouldn't that mean that we're erasing other content?  The "erase"
> > > plugins memset the output data to a chosen value (or 0), whereas the
> > > filtering just drops the page.  Couldn't this also lead to a situation
> > > where the debugger can't find the page at all, versus giving us one
> > > that's sanitized?  (I do understand why you want to drop the pages for
> > > the GPU cases)
> >
> > Frankly I didn't consider the data erasing as in-depth as you did. I
> > think you are right, makedumpfile needs to know which extensions
> > handle data erasing and which handle mm page filtering. I guess the mm
> > page filtering extensions will need to perform a "dry-run" filter
> > first, in case the "data erasing" extensions break any useful data
> > structure. In this step, "dry-run" will only record pfn numbers of the
> > pages that will be filtered. Then "data erasing" extensions are
> > called, so all the sensitive data is memset to 0. Finally, all desired
> > pages are filtered out based on the previous recording.
> >
> > With this, "data erase" and "page filtering" will not interfere with
> > each other. What do you think?
>
> This is a great point.  It's probably worth documenting the precedence
> order in which these callbacks are expected to be applied.  Naively, I
> might expect filtering pages to take precedence over erasing data
> structures.  For the GPU cases, these are orthogonal.  However, for
> something where a user might be both trying to filter the page and erase
> matching content, we don't have any rules defined.  It's probably less
> surprising to allow pages to be filtered first.  (I think it is this way
> in the code.) It also prevents the page filtering from completely
> filtering a page.
>
> > > > > Would you be willing to modify the extension registration options to
> > > > > allow an extension to specify what kind it is? That way, in the future
> > > >
> > > > I'm not sure what you mean by "what kind". Do you mean an extension
> > > > needs to tell makedumpfile what purpose it is for when loading?
> > >
> > > Yes, sorry I wasn't clear in writing the question.  Stating this
> > > differently, if we want to allow the ability for different extensions to
> > > do different things, how do the extensions declare to makedumpfile what
> > > they can do, so that it knows where to invoke their callbacks, and what
> > > callbacks of theirs to invoke.
> > >
> > > Looking at patch 6/9, right now run_extension_callback() is involved
> > > from __exclude_unncessary_pages and always calls the
> > > "extension_callback" symbol in the module.  This makes sense for a
> > > single extension type that's focused on filtering pages.  However, if we
> > > wanted to have multiple different extensions, this might be more
> > > difficult.
> > >
> > > If we could determine what type of functionality the module implements
> > > in load_extensions, then we could tell if this is a page filtering
> > > extension, an erase extension, or some other kind of extension.
> > >
> > > For example, for an erase filter, perhaps we would want two callbacks:
> > > one to set up the ranges to filter "extension_gather_callback" and
> > > another to actuallyf check the address range to see if it is filtered,
> > > "extension_filter_data_callback"
> > >
> > > I'm not sure about the names.  "extension_callback" seems generic, but
> > > this has a specific purpose.  It's a "extension_filter_page_callback"
> > >
> > > I may be overengineering this a bit, but having makedumpfile pass an ops
> > > vector to the extension in a load function could help here.  Then the
> > > module's load function fills out the vector with the functions it
> > > supports.  Depending on what's implemented, these can be placed into
> > > different callback lists to get invoked at different points in the
> > > program (e.g. one at pfn filter time, another in filter_data_buffer,
> > > etc).
> > >
> > > It sounds like you had a plan here, though.  Were you thinking of adding
> > > new extension types a different way?
> >
> > I see your idea: makedumpfile predefines a few hook points at
> > different stages, and extensions can register their callbacks to these
> > hook points. For now I think 2 hook points are enough, one for page
> > filtering and other one for resiger the data erasing, which definitely
> > shouldn't be within __exclude_unnecessary_pages().
> >
> > I'm willing to modify the code. Such as implementing a hooking point
> > registration/management. But since I haven't work on the data erasing
> > functions so far, the design might be superficial, personally I'd
> > prefer to do this along with the data erasing functions in the next
> > independent patchset, considering current patchset we already includes
> > plenty of code/function implementations. @maintainers, What's your
> > opinion?
>
> Just to clarify, I'm not asking that you implement any erase
> functionality in the current patchset.  Rather, asking if there's a way
> to implement the current functionality such that the extension modules
> won't need recompilation when a new extension type is introduced. I
> think there are a number of different ways to do this, but I didn't want
> to be overly prescriptive in my feedback.
>
> Thanks again,
>
> -K
>