linux-kernel - Re: [PATCH v2 2/3] memory: export symbols for memory related functions

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: <ZIn0rMjYESJHuzyg@casper.infradead.org>
Date:   Wed, 14 Jun 2023 18:11:08 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Wei-chin Tsai (蔡維晉) 
        <Wei-chin.Tsai@...iatek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mel Lee (李奇錚) <Mel.Lee@...iatek.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        Ivan Tseng (曾志軒) 
        <ivan.tseng@...iatek.com>
Subject: Re: [PATCH v2 2/3] memory: export symbols for memory related
 functions

On Wed, Jun 14, 2023 at 05:21:43PM +0100, Russell King (Oracle) wrote:
> What I'm trying to get at is that we have arch_vma_name in
> arch/arm/kernel/process.c and also a weak function in kernel/signal.c.
> 
> Both of these end up adding an entry into the __ksymtab_strings
> section and a ___ksymtab section for this symbol. So we end up with
> two entries in each.
> 
> Now, if the one from kernel/signal.c points at its own weak function,
> and that is found first, then that's the function that is going to be
> bound, not the function that's overriding it.
> 
> If, instead, the export in kernel/signal.c ends up pointing at the
> overriden function, then the export in arch/arm/kernel/process.c is
> entirely redundant.
> 
> So, you need to get to the bottom of this... and until you do I'm
> afraid I'll have to NAK this patch.

I think the patch should be NAKed indefinitely.  I had a quick look at
the user, and it seems like something is being done in the kernel that
should be done in userspace.