linux-kernel - Re: [PATCH v6 4/9] ovl: Create ovl_casefold() to support casefolded strncmp()

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: <564e46ac-a605-4b20-bb48-444bf7141ab5@igalia.com>
Date: Tue, 26 Aug 2025 16:58:20 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Gabriel Krisman Bertazi <krisman@...e.de>,
 Amir Goldstein <amir73il@...il.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, Theodore Tso <tytso@....edu>,
 linux-unionfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 kernel-dev@...lia.com
Subject: Re: [PATCH v6 4/9] ovl: Create ovl_casefold() to support casefolded
 strncmp()



Em 26/08/2025 12:02, Gabriel Krisman Bertazi escreveu:
> Amir Goldstein <amir73il@...il.com> writes:
> 
>> On Tue, Aug 26, 2025 at 3:34 AM Gabriel Krisman Bertazi <krisman@...e.de> wrote:
>>
>>>
>>> I was thinking again about this and I suspect I misunderstood your
>>> question.  let me try to answer it again:
>>>
>>> Ext4, f2fs and tmpfs all allow invalid utf8-encoded strings in a
>>> casefolded directory when running on non-strict-mode.  They are treated
>>> as non-encoded byte-sequences, as if they were seen on a case-Sensitive
>>> directory.  They can't collide with other filenames because they
>>> basically "fold" to themselves.
>>>
>>> Now I suspect there is another problem with this series: I don't see how
>>> it implements the semantics of strict mode.  What happens if upper and
>>> lower are in strict mode (which is valid, same encoding_flags) but there
>>> is an invalid name in the lower?  overlayfs should reject the dentry,
>>> because any attempt to create it to the upper will fail.
>>
>> Ok, so IIUC, one issue is that return value from ovl_casefold() should be
>> conditional to the sb encoding_flags, which was inherited from the
>> layers.
> 
> yes, unless you reject mounting strict_mode filesystems, which the best
> course of action, in my opinion.
> 
>>
>> Again, *IF* I understand correctly, then strict mode ext4 will not allow
>> creating an invalid-encoded name, but will strict mode ext4 allow
>> it as a valid lookup result?
> 
> strict mode ext4 will not allow creating an invalid-encoded name. And
> even lookups will fail.  Because the kernel can't casefold it, it will
> assume the dirent is broken and ignore it during lookup.
> 
> (I just noticed the dirent is ignored and the error is not propagated in
> ext4_match.  That needs improvement.).
> 
>>>
>>> André, did you consider this scenario?
>>
>> In general, as I have told Andre from v1, please stick to the most common
>> configs that people actually need.
>>
>> We do NOT need to support every possible combination of layers configurations.
>>
>> This is why we went with supporting all-or-nothing configs for casefolder dirs.
>> Because it is simpler for overlayfs semantics and good enough for what
>> users need.
>>
>> So my question is to you both: do users actually use strict mode for
>> wine and such?
>> Because if they don't I would rather support the default mode only
>> (enforced on mount)
>> and add support for strict mode later per actual users demand.
> 
> I doubt we care.  strict mode is a restricted version of casefolding
> support with minor advantages.  Basically, with it, you can trust that
> if you update the unicode version, there won't be any behavior change in
> casefolding due to newly assigned code-points.  For Wine, that is
> irrelevant.
> 
> You can very well reject strict mode and be done with it.
> 

Amir,

I think this can be done at ovl_get_layers(), something like:

if (sb_has_strict_encoding(sb)) {
	pr_err("strict encoding not supported\n");
	return -EINVAL;
}