linux-hardening - Re: [PATCH v2 00/10] lib/string

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: <CAHp75VdJvs-K3jVVuKkisQ0d=3s0bbyNthUKmDa0T58MjnoSNw@mail.gmail.com>
Date: Tue, 4 Mar 2025 09:01:43 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc: Andy Shevchenko <andy@...nel.org>, Kees Cook <kees@...nel.org>, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 00/10] lib/string_choices: Add new helpers

On Tue, Mar 4, 2025 at 8:53 AM Kuninori Morimoto
<kuninori.morimoto.gx@...esas.com> wrote:

...

> > >         passed     / failed
> > >         succeed    / failed
> > >         success    / failed
> > >         successful / failed
> > >         succeeded  / failed
> > >         worked     / failed
> >
> > It looks like something with the 'successful' / 'succeeded' needs to be
> > present.
> >
> > But in general here is the BIG NOTE: some of the strings may be used
> > in ABI, which must not change them.
>
> It is indeed one of my concern.
> Not only above, but some drivers are using capital letters at the beginning,
> but helper uses all lowercase...
>
> I agree we should not change string if it was used on dev_info() or something.

dev_*() are not the ABI.

> But I think it can be more flexible if it was used on dev_dbg() ? not sure...

All dev_*() and pr_*() and their derivatives may use these helpers
without thinking of any breakages.

On the contrary sysfs nodes, s*printf() when used to prepare strings
to communicate with the user space and so on are all the ABIs. You
need to study case-by-case. That's why I suggest you reduce this
series to just helpers necessary for let say gpio-crystalcove and
gpio-wcove drivers which I can review and ack and that's what will
have all chances to go in this cycle. Then repeat for other helpers,
no need to send tons of helpers with tons of conversion
patches/samples. Do small steps at a time.

That said, I would expect the series out of 3/4 patches
1) add str_in_out() and/or str_input_output();
2) use it in gpio-crystalcove.c
3) use it in gpio-wcove.c

This can be easily combined into an immutable tag/branch and pulled by
the affected subsystems. With your lengthy series it will be ages to
get it in.

> I will indicate it (= the strings might be changed) on the patch in Step2,
> and follow each maintainer / reviewer opinion. Is it OK for you ?
>
> But hmm... I will double check the new helper, some of them might not needed
> if it was used only on dev_info()...

-- 
With Best Regards,
Andy Shevchenko