linux-kernel - Re: [PATCH v6 0/6] ioctl()-based API to query VMAs from /proc/<pid>/maps

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]

Date: Fri, 28 Jun 2024 09:42:19 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Andrii Nakryiko <andrii@...nel.org>, linux-fsdevel@...r.kernel.org, brauner@...nel.org, 
	viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org, bpf@...r.kernel.org, 
	gregkh@...uxfoundation.org, linux-mm@...ck.org, liam.howlett@...cle.com, 
	surenb@...gle.com, rppt@...nel.org, adobriyan@...il.com
Subject: Re: [PATCH v6 0/6] ioctl()-based API to query VMAs from /proc/<pid>/maps

On Thu, Jun 27, 2024 at 2:11 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Thu, 27 Jun 2024 13:50:22 -0700 Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>
> > On Thu, Jun 27, 2024 at 12:59 PM Andrew Morton
> > > Is it possible/sensible to make this feature Kconfigurable so that people who
> > > don't need it can omit it?
> >
> > It's just a matter of #ifdef/#endif, so not hard, technically
> > speaking. But I'm wondering what's the concern? This is mostly newly
> > added code (except factoring out get_vma_name logic, which won't be
> > #ifdef'ed anyways), so if no one is using this new API, then it should
> > cause no issue.
> >
> > Generally speaking, I'd say if we don't *have to* add the Kconfig
> > option, I'd prefer that. But if you feel strongly, it's not hard for
> > me to do, of course.
> >
> > Or are you concerned with the vmlinux code size increase? It doesn't
> > seem to be large enough to warrant a Kconfig, IMO (from
> > bloat-o-meter):
> >
> > do_procmap_query                               -    1308   +1308
> > get_vma_name                                   -     283    +283
> > procfs_procmap_ioctl                           -      47     +47
> > show_map_vma                                 444     274    -170
> >
> > But again, do let me know if you insist.
>
> Yes, I'm thinking about being nice to small systems ("make
> tinyconfig"!).  The kernel just gets bigger and bigger over time,
> little bit by little bit.
>
> It's a judgment call - if making it configurable is ugly and/or adds
> maintenance overhead then no.
>

I see, thanks for clarifying. I'd vote to not add extra Kconfig to
keep things simple and less surprising. All this code is conditional
on CONFIG_PROC_FS=y anyways, and there is plenty of code for procfs
already. I think this do_procmap_query is just a small addition here
that doesn't fundamentally regress anything.