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:   Mon, 17 Apr 2023 09:16:49 -0700
From:   Will McVicker <>
To:     "Theodore Ts'o" <>
Cc:     Christoph Hellwig <>,
        Christoph Hellwig <>,,
        "Stephen E. Baker" <>,
Subject: Re: simplify ext4_sb_read_encoding regression

On Sun, Apr 16, 2023 at 8:26 PM Theodore Ts'o <> 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.


Powered by blists - more mailing lists