linux-kernel - Re: [PATCH RFC 0/4] Introduce uts

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] [day] [month] [year] [list]

Date: Wed, 21 Feb 2024 20:50:42 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: John Garry <john.g.garry@...cle.com>
Cc: mcgrof@...nel.org, russ.weight@...ux.dev, gregkh@...uxfoundation.org, 
	rafael@...nel.org, rostedt@...dmis.org, mhiramat@...nel.org, 
	mathieu.desnoyers@...icios.com, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, keescook@...omium.org, nathan@...nel.org, 
	nicolas@...sle.eu, linux-kernel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, netdev@...r.kernel.org, 
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH RFC 0/4] Introduce uts_release

On Wed, Feb 21, 2024 at 6:01 PM John Garry <john.g.garry@...cle.com> wrote:
>
> On 08/02/2024 10:08, John Garry wrote:
> > On 05/02/2024 23:10, Masahiro Yamada wrote:
> >>>> I think what you can contribute are:
> >>>>
> >>>>    - Explore the UTS_RELEASE users, and check if you can get rid of it.
> >>> Unfortunately I expect resistance for this. I also expect places like FW
> >>> loader it is necessary. And when this is used in sysfs, people will say
> >>> that it is part of the ABI now.
> >>>
> >>> How about I send the patch to update to use init_uts_ns and mention also
> >>> that it would be better to not use at all, if possible? I can cc you.
> >>
> >> OK.
> >>
> >>
> >> As I mentioned in the previous reply, the replacement is safe
> >> for builtin code.
> >>
> >> When you touch modular code, please pay a little more care,
> >> because UTS_RELEASE and init_utsname()->release
> >> may differ when CONFIG_MODVERSIONS=y.
> >>
> >
> > Are you saying that we may have a different release version kernel and
> > module built with CONFIG_MODVERSIONS=y, and the module was using
> > UTS_RELEASE for something? That something may be like setting some info
> > in a sysfs file, like in this example:
> >
> > static ssize_t target_core_item_version_show(struct config_item *item,
> >          char *page)
> > {
> >      return sprintf(page, "Target Engine Core ConfigFS Infrastructure %s"
> >          " on %s/%s on "UTS_RELEASE"\n", TARGET_CORE_VERSION,
> >          utsname()->sysname, utsname()->machine);
> > }
> >
> > And the intention is to use the module codebase release version and not
> > the kernel codebase release version. Hence utsname() is used for
> > .sysname and .machine, but not .release .
>
> Hi Masahiro,
>
> Can you comment on whether I am right about CONFIG_MODVERSIONS, above?
>
> Thanks,
> John



Your understanding about CONFIG_MODVERSIONS is correct.




-- 
Best Regards
Masahiro Yamada