linux-ext4 - Re: [PATCH 17/20] ext4: Include encoding information in the superblock

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:   Thu, 12 Jul 2018 10:13:14 -0400
From:   Gabriel Krisman Bertazi <krisman@...labora.co.uk>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org, darrick.wong@...cle.com,
        kernel@...labora.com
Subject: Re: [PATCH 17/20] ext4: Include encoding information in the superblock

"Theodore Y. Ts'o" <tytso@....edu> writes:

> As the kbuild bot has already reported, you've added an unconditional
> dependency on the NLS subsystem, which is not always compiled in.
> What we need to do is to add #ifdef's on CONFIG_NLS, and only support
> file systems with encoding if the kernel is compiled with CONFIG_NLS.

Thanks, I will address this in the next iteration.

> One thought --- do we really need to use CONFIG_NLS if the encoding is
> ASCII?  If some use case (and Android may be one) only is interested
> in supporting case-folding for ASCII, and they don't want to have the
> overhead of compiling in the NLS subsystem, for ASCII couldn't use
> just use strcasecmp() for its comparison function?

My concern here is that the casefold and normalization operations don't
make sense, semantically, when dealing with opaque byte sequences.  We
can assume that no-encoding means ASCII, but this is an arbitrary
decision, that only make sense for english speakers.  I think it is
safer/less confusing to only allow this kind of operation when an
explicit encoding format is in place.

Is the dependency on NLS a problem for Android?  I assumed it already
has to enable it anyway to support fat filesystems.  For use cases other
than Android, I'm trying to reduce the footprint of NLS, by making it
more modular (and we could even make it smaller by reducing the
nls_default.c code and doing the ASCII operations algorithmically
instead of using tables), such that building NLS core + ASCII should
have a really tiny impact on the kernel size and build time (which I
think it already does?)

> The normalization for ASCII is the identify function, so it's kind of
> pointless to support ASCII if we ony have case-folding support and not
> normalization for now, right?

Yes.  the ASCII normalization is boilerplate code, in a sense, since it
is just the identity function, but I'm trying to make the NLS interface
generic enough to minimize how much EXT4 needs to know about encoding.
Ideally, this knowledge should be left for the NLS system, in my
opinion.  Does it make sense?

Thanks,

-- 
Gabriel Krisman Bertazi