linux-kernel - Re: [PATCH v2] modpost: move the namespace field in Module.symvers last

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:   Tue, 17 Mar 2020 09:24:14 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Jessica Yu <jeyu@...nel.org>
Cc:     Matthias Maennich <maennich@...gle.com>,
        Lucas De Marchi <lucas.de.marchi@...il.com>,
        stable <stable@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] modpost: move the namespace field in Module.symvers last

On Sat, Mar 14, 2020 at 11:11 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> On Thu, Mar 12, 2020 at 2:02 AM Jessica Yu <jeyu@...nel.org> wrote:
> >
> > In order to preserve backwards compatability with kmod tools, we have to
> > move the namespace field in Module.symvers last, as the depmod -e -E
> > option looks at the first three fields in Module.symvers to check symbol
> > versions (and it's expected they stay in the original order of crc,
> > symbol, module).
> >
> > In addition, update an ancient comment above read_dump() in modpost that
> > suggested that the export type field in Module.symvers was optional. I
> > suspect that there were historical reasons behind that comment that are
> > no longer accurate. We have been unconditionally printing the export
> > type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now.
> >
> > Fix up read_dump() to treat each field as non-optional. I suspect the
> > original read_dump() code treated the export field as optional in order
> > to support pre <= 2.6.18 Module.symvers (which did not have the export
> > type field). Note that although symbol namespaces are optional, the
> > field will not be omitted from Module.symvers if a symbol does not have
> > a namespace. In this case, the field will simply be empty and the next
> > delimiter or end of line will follow.
> >
> > Cc: stable@...r.kernel.org
> > Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces")
> > Tested-by: Matthias Maennich <maennich@...gle.com>
> > Reviewed-by: Matthias Maennich <maennich@...gle.com>
> > Reviewed-by: Lucas De Marchi <lucas.demarchi@...el.com>
> > Signed-off-by: Jessica Yu <jeyu@...nel.org>
>
>
> While I am not opposed to this fix,
> I did not even notice Module.symvers was official interface.
>
> Kbuild invokes scripts/depmod.sh to finalize
> the 'make modules_install', but I do not see the -E
> option being used there.
>
> I do not see Module.symvers installed in
> /lib/modules/$(uname -r)/.
>
>
>



Applied to linux-kbuild/fixes.



-- 
Best Regards
Masahiro Yamada