linux-kernel - Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat

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] [day] [month] [year] [list]

Date:   Sun, 08 Sep 2019 19:50:16 +0900
From:   OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Valdis Klētnieks <valdis.kletnieks@...edu>,
        Christoph Hellwig <hch@...radead.org>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of
 fat/vfat

Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:

> On Mon, Sep 02, 2019 at 03:00:17PM -0400, Valdis Klētnieks wrote:
>> On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said:
>> 
>> > I dug up my old discussion with the current vfat maintainer and he said
>> > something to the affect of, "leave the existing code alone, make a new
>> > filesystem, I don't want anything to do with exfat".
>> >
>> > And I don't blame them, vfat is fine as-is and stable and shouldn't be
>> > touched for new things.
>> >
>> > We can keep non-vfat filesystems from being mounted with the exfat
>> > codebase, and make things simpler for everyone involved.
>> 
>> Ogawa:
>> 
>> Is this still your position, that you want exfat to be a separate module?
>
> Personally I agree that this should be separate at least for quite some
> time to shake things out at the very least.  But I'll defer to Ogawa if
> he thinks things should be merged.

I'm not reading whole of this thread, so I can be pointless though. I
can't recall the discussion of exfat with you. My history about exfat
is,

   write read-only exfat from on-disk data -> MS published patent to
   their site or such -> stopped about exfat -> recently looks like MS
   changed mind

Well, if you are going to developing actively, IMO it would be better to
drop historically bad decisions in fat driver (some stuff would be hard
to fix without user visible changes), and re-think from basic
implementation design.

And I can't recall the detail of exfat format though, IIRC, the common
code is not so big, but some stuff can be shared with fat (timestamp
stuff, fatent stuff, IIRC). So IMO it is better to be different driver
basically, however on other hand, it is better to share the code for
same on-disk format if possible.

Anyway, I don't have strong opinion about it.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>