linux-ext4 - Re: simplify ext4_sb_read

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]

Message-ID: <CABYd82ZX_HPrUONwNp+=A_zUa1m15PPnJcjO=BCsWZeVLVzf=Q@mail.gmail.com>
Date:   Mon, 17 Apr 2023 09:16:49 -0700
From:   Will McVicker <willmcvicker@...gle.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Christoph Hellwig <hch@....de>, linux-ext4@...r.kernel.org,
        "Stephen E. Baker" <baker.stephen.e@...il.com>,
        adilger.kernel@...ger.ca
Subject: Re: simplify ext4_sb_read_encoding regression

On Sun, Apr 16, 2023 at 8:26 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Sat, Apr 15, 2023 at 10:56:23PM -0700, Christoph Hellwig wrote:
> > On Sun, Apr 16, 2023 at 07:47:42AM +0200, Christoph Hellwig wrote:
> > > We could do that, but it seems a bit ugly.  What prevents symbol_request
> > > from working properly for this case in your setup?
> >
> > To anwer to myself - I guess we need something else than a plain
> > EXPORT_SYMBOL for everything that is used by
> > symbol_request.  Which would be a nice cleanly anyway - exports for
> > symbol_request aren't normal exports and should probably have a clear
> > marker just to stand out anyway.
>
> Agreed, that's the best/cleanest long-term solution.
>
> The short-term hack that William could use in the interim would be to
> simply configure CONFIG_UNUSED_KSYMS_WHITELIST to include
> 'utf8_data_table', which will solve his immediate problem without
> needing to maintain an out-of-tree patch in his kernel.
>
> Presumably, that's what the long-term solution would effectively do,
> except it would be automated as opposed to requiring people who use
> CONFIG_TRIM_UNUSED_KSYMS to have to do manually.  Note also that there
> are only a half-dozen or so such symbols in the Linux kernel today, so
> while we could and probably should automate it, it's not clear to me
> the number of use cases where CONFIG_TRIM_UNUSED_KSYMS is going to be
> relevant are very likely quite small.  (The only ones I can think of
> are the Android Generic Kernel Image and for enterprise Linux
> distributions.  And in both cases, I suspect those use cases will
> probably have a very large list of symbol added to the allow list, so
> adding those few extra symbols is probably going to be in the noise.
>
>                                                 - Ted

Thanks for the responses! I was missing the part that utf8-core.c is always
built into the kernel when CONFIG_UNICODE is enabled. So it makes sense
to me why we need to use symbol_request() vs just EXPORT_SYMBOL. It
should be fine for us to include this symbol in our symbol list.

Thanks,
Will