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:   Sun, 16 Apr 2023 23:26:05 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Christoph Hellwig <hch@....de>,
        William McVicker <willmcvicker@...gle.com>,
        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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ