linux-kernel - Re: [RFC PATCH 11/20] hfs: Explicitly set hsb->nls_disk when hsb->nls

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: <E85E6FF7-AA14-4FA6-82AA-859D93BD0069@dubeyko.com>
Date:   Mon, 9 Aug 2021 11:00:29 -0700
From:   Viacheslav Dubeyko <slava@...eyko.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Pali Rohár <pali@...nel.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        linux-ntfs-dev@...ts.sourceforge.net, linux-cifs@...r.kernel.org,
        jfs-discussion@...ts.sourceforge.net,
        LKML <linux-kernel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Jan Kara <jack@...e.cz>,
        OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Luis de Bethencourt <luisbg@...nel.org>,
        Salah Triki <salah.triki@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dave Kleikamp <shaggy@...nel.org>,
        Anton Altaparmakov <anton@...era.com>,
        Pavel Machek <pavel@....cz>,
        Marek Behún <marek.behun@....cz>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [RFC PATCH 11/20] hfs: Explicitly set hsb->nls_disk when
 hsb->nls_io is set



> On Aug 9, 2021, at 10:37 AM, Matthew Wilcox <willy@...radead.org> wrote:
> 
> On Mon, Aug 09, 2021 at 10:31:55AM -0700, Viacheslav Dubeyko wrote:
>>> On Aug 8, 2021, at 9:24 AM, Pali Rohár <pali@...nel.org> wrote:
>>> 
>>> It does not make any sense to set hsb->nls_io (NLS iocharset used between
>>> VFS and hfs driver) when hsb->nls_disk (NLS codepage used between hfs
>>> driver and disk) is not set.
>>> 
>>> Reverse engineering driver code shown what is doing in this special case:
>>> 
>>>   When codepage was not defined but iocharset was then
>>>   hfs driver copied 8bit character from disk directly to
>>>   16bit unicode wchar_t type. Which means it did conversion
>>>   from Latin1 (ISO-8859-1) to Unicode because first 256
>>>   Unicode code points matches 8bit ISO-8859-1 codepage table.
>>>   So when iocharset was specified and codepage not, then
>>>   codepage used implicit value "iso8859-1".
>>> 
>>> So when hsb->nls_disk is not set and hsb->nls_io is then explicitly set
>>> hsb->nls_disk to "iso8859-1".
>>> 
>>> Such setup is obviously incompatible with Mac OS systems as they do not
>>> support iso8859-1 encoding for hfs. So print warning into dmesg about this
>>> fact.
>>> 
>>> After this change hsb->nls_disk is always set, so remove code paths for
>>> case when hsb->nls_disk was not set as they are not needed anymore.
>> 
>> 
>> Sounds reasonable. But it will be great to know that the change has been tested reasonably well.
> 
> I don't think it's reasonable to ask Pali to test every single filesystem.
> That's something the maintainer should do, as you're more likely to have
> the infrastructure already set up to do testing of your filesystem and
> be aware of fun corner cases and use cases than someone who's working
> across all filesystems.

I see the point. But the whole approach needs to be tested as minimum for one particular file system. :) And it could be any favorite one.

Thanks,
Slava.