linux-kernel - Re: [PATCH v7 3/3] check-module-params: Introduce check-module-params.sh

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: <CAK7LNAQfzxiMoiLXvksUWtPiRhXQ7zypUzQpYER_7B=00XBr=A@mail.gmail.com>
Date: Sat, 23 Dec 2023 02:57:00 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: John Moon <quic_johmoo@...cinc.com>
Cc: Christoph Hellwig <hch@...radead.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Nicolas Schier <nicolas@...sle.eu>, 
	Jonathan Corbet <corbet@....net>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org, 
	kernel@...cinc.com, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Rob Herring <robh@...nel.org>, "Carlos O'Donell" <carlos@...hat.com>, 
	Randy Dunlap <rdunlap@...radead.org>, Arnd Bergmann <arnd@...db.de>, 
	Bjorn Andersson <andersson@...nel.org>, Todd Kjos <tkjos@...gle.com>, 
	Matthias Maennich <maennich@...gle.com>, Giuliano Procida <gprocida@...gle.com>, kernel-team@...roid.com, 
	libabigail@...rceware.org, Dodji Seketeli <dodji@...hat.com>, 
	Trilok Soni <quic_tsoni@...cinc.com>, 
	Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com>, Jordan Crouse <jorcrous@...zon.com>
Subject: Re: [PATCH v7 3/3] check-module-params: Introduce check-module-params.sh

On Wed, Dec 13, 2023 at 1:58 AM John Moon <quic_johmoo@...cinc.com> wrote:
>
> On 12/11/2023 11:41 PM, Christoph Hellwig wrote:
> > On Mon, Dec 11, 2023 at 06:02:59PM -0800, John Moon wrote:
> >> One part of maintaining backwards compatibility with older
> >> userspace programs is avoiding changes to module parameters.
> >
> > Really?  I don't think module parameters are a UAPI in the traditional
> > sense.
>
> Agreed, they're not UAPI in the traditional sense. But, we're trying to
> establish tooling to help the community stabilize all interfaces that
> cross the kernel <-> userspace boundary and module params do fall into
> that bucket.
>
> > Now if you break a heavily used one you got to fix it, but
> > applying strict stability guarantees on module options which are not
> > availble to normal users or even normal programs doesn't make a whole
> > lot of sense.
> >
>
> True, but unfortunately we don't have any heuristic to determine if a
> param is "heavily used". However, in this rev, we added the ability to
> parse the permissions of a module param, so we could add a filter which
> does not flag change/removal of params with 0{0,4,6}000 permissions.
>
> It's also obviously fine if the community has no interest in the script.
> We just wanted to share it as we find it to be a useful supplement to
> our code reviews and thought maintainers may find it useful as well.
>
> Cheers,
> John


I am with Christoph.

This tool detects some changes and removals, but I think
the community intentionally changed them.

To merge this tool in the mainline,
I need more people who are interested in this.




-- 
Best Regards
Masahiro Yamada