linux-kernel - Re: [PATCH] staging: exfat: add exfat filesystem code to staging

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: <86151.1581718578@turing-police>
Date:   Fri, 14 Feb 2020 17:16:18 -0500
From:   "Valdis Klētnieks" <valdis.kletnieks@...edu>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Pali Rohár <pali.rohar@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Sasha Levin <alexander.levin@...rosoft.com>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to staging

On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said:

> >> I was hoping that it would be possible to easily use secondary FAT table
> >> (from TexFAT extension) for redundancy without need to implement full
> >> TexFAT, which could be also backward compatible with systems which do
> >> not implement TexFAT extension at all. Similarly like using FAT32 disk
> >> with two FAT tables is possible also on system which use first FAT
> >> table.

OK.. maybe I'm not sufficiently caffeinated, but how do you use 2 FAT tables on
a physical device and expect it to work properly on a system that uses just the
first FAT table, if the device is set to "use second table" when you mount it?
That sounds just too much like the failure modes of running fsck on a mounted
filesystem....

> >By the chance, is there any possibility to release TexFAT specification?
> >Usage of more FAT tables (even for Linux) could help with data recovery.
>
> This would be a major pain in the arse to pull off (even more that
> releasing exFAT itself) because TexFAT is effectively dead and no one
> here cares about it. It's not even the case that there are devices which
> are now left unsupported, the whole TexFAT scheme is just dead and gone.
>
> Could I point you to the TexFAT patent instead
> (https://patents.google.com/patent/US7613738B2/en)? It describes well
> how TexFAT used to work.

I don't think anybody wants the full TexFAT support - but having a backup copy
of the FAT would be nice in some circumstances.

Actually, that raises an question....

What the published spec says:

The File Allocation Table (FAT) region may contain up to two FATs, one in the
First FAT sub-region and another in the Second FAT sub-region. The NumberOfFats
field describes how many FATs this region contains. The valid values for the
NumberOfFats field are 1 and 2. Therefore, the First FAT sub-region always
contains a FAT. If the NumberOfFats field is two, then the Second FAT
sub-region also contains a FAT.

The ActiveFat field of the VolumeFlags field describes which FAT is active.
Only the VolumeFlags field in the Main Boot Sector is current. Implementations
shall treat the FAT which is not active as stale. Use of the inactive FAT and
switching between FATs is implementation specific.

Sasha:  can you find out what the Windows implementation does regarding that
last sentence?  Does it actively use both FAT sub-regions and switch between
them (probably not), or does it read the ActiveFAT value and use that one, or
does Windows just use NumberOfFats == 1?

I'm assuming that the fact the doc also says "NumberOfFats == 2 is only valid
for TexFAT volumes" possibly means "Microsoft thinks that's hardcoded at 1"
given the death of TexFAT.  That would make adding alternate FAT support a
major challenge.

On the other hand, if Windows actually looks at the NumberOfFats value, finds
a 2, and ActiveFAT ==1 (meaning use second table) and says "OK, whatever" and
just uses the second table from there on out, it becomes a lot easier.

Content of type "application/pgp-signature" skipped