linux-kernel - Re: CONFIG_VFAT_FS

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:	Tue, 21 Jul 2009 12:16:13 +0300
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	tridge@...ba.org
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	Theodore Tso <tytso@....edu>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org, torvalds@...ux-foundation.org
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

On 07/21/2009 06:37 AM, tridge@...ba.org wrote:
> Thanks to everyone who helped with the testing of the previous round
> of VFAT patent workaround patches.
> 
> I've posted a new set of patches today which tries to address some of
> the technical problems found in the last patch.
> 
> The new patches:
> 
>   - work with Win98
>   - work with Jan's IOneIt MP3 player
>   - work with all the other FAT capable devices I have available for
>     testing
>   - work with existing copies of mtools
> 
> The remaining issues that I am aware of are:
> 
>   - There is a cosmetic issue with the DOS command prompt under
>     Win98. A directory listing works, but displays garbage in the
>     column where a 8.3 short filename would normally go
> 
>   - Similarly, under WinXP, a "dir/x" will show garbage in the 8.3
>     column. For example: http://samba.org/~tridge/dir_test.png
> 

I guess you tried putting a zero at first char and it breaks everybody?

>   - mtools has a similar cosmetic issue, which is fixed with a small
>     patch
> 
>   - devices which only support 8.3 filenames will not be able to see
>     or use files created with long names with the patch enabled
> 
>   - There is a very small chance of WinXP bluescreening if two files
>     in the same directory have the same 11 dummy bytes, and are
>     accessed in quick succession. The chances of this happening is
>     approximately 80x smaller than with the previous patch. As
>     previously noted, this is a very difficult problem to reproduce,
>     and in fact nobody has managed to reproduce it without modifying
>     the patch to use a much smaller number of random bits.
> 

I guess (35^6)*8*7 is not that bad

>   - Similarly, there is a small chance that chkdsk on Windows will
>     rename one file in a directory if they happen to have the same 11
>     byte dummy values. The probability of this happening is
>     approximately 80x lower than with the previous patch.
> 

What if we had a user mode utility that does these short-names
renames that a user can optionally run after umount? since it
only writes the (random) short-names it's also safe.

Kind of the cop that can read and the cop that can write e-literacy
problem, No?

> Some people have also asked that this patch change the name of the
> filesystem to 'lfat' or similar. I have not included that change in
> this patch as I think it is counter productive. Instead I have added a
> printk_once() to produce a warning like this:
> 
>   VFAT: not creating 8.3 short filenames for long names
> 
> when the first long filename is created on a VFAT filesystem with this
> patch enabled.
> 
> The reason I think this is a better option than a filesystem name
> change is that a name change will break a unknown number of userspace
> tools, scripts and config files. For example, desktop tools for
> mounting filesystems, scripts that use -t vfat, module configuration
> options in /etc could all be broken without any ability to give the
> user feedback on why it broke.
> 
> If you have a FAT capable device that you want to test for
> compatibility with the new patches, please have a look at the
> 'Testing' section of the following README:
> 
>   http://kernel.org/pub/linux/kernel/people/tridge/VFAT/README
> 
> It gives details on how you can do testing without having to change
> your kernel.
> 
> Cheers, Tridge
> --

Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/