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

Am Dienstag 07 Juli 2009 schrieb tridge@...ba.org:
> I've now done some experiments, and I have reproduced the problem you
> saw. I've also experimented with changing the
> vfat_build_dummy_83_buffer() to try some other combinations. I've
> found that with a simple memset(msdos_name, ' ', 11) that Win98 works
> pretty well:
>
>   http://picpaste.com/Win98-longnames.png
>
> It does show one error though. In the DOS box directory listing on the
> left notice that it shows both a long name and a short name for the
> files, with the long name being a truncated form of the short
> name. The normal commands like xcopy, notepad etc all seem to work
> fine though, so practical compatibility seems pretty good.
>
> The problem with that simple memset() approach with spaces is that it
> would cause more crashes with WinXP. It does show that there might be
> some other combination that works with both though. I'll play a bit
> more and see what I can find.
>
>  > This dualnames patch just won't fly in practice.
>
> well, "won't fly" depends on your POV I guess. Unless we're hoping
> that all the Microsoft lawyers take early retirement, I think we do
> need to have some strategy to avoiding more companies having the same
> problems that TomTom had.

Following this thread I get more and more the impression that this patch 
is playing roulette regarding compatibility with countless devices which 
use fat/vfat, with different Windows versions and with countless Windows 
applications including but not limited to low level filesystem check, 
repair and cloning tools. And I start to get the impression that it 
becomes unmanageably complex to make a clear assessment on compatibility 
in all those circumstances. Thus I can't figure how a realistic assessment 
on the impact of this patch could be made.

Have low level filesystem check, repair and cloning tools been checked 
against the patch at all?

I think the patch actively *corrupts* perfectly fine shortname FAT 
filesystems and at least for certain use scenarios even those with long 
name support.

Thus I would certainly not enable it unless forced too - already just for 
*technical* reasons. I probably would even default to compile my own 
kernel when I find that the distribution of my choice (Debian) would enable 
it.

Politically spoken I think the patch tries to workaround a problem that 
better is fixed properly and causes a precedence for other politically, 
juristically motivated patches. If the Linux kernel would be changed to 
avoid any software patent issues I am not sure whether it would even be 
able to boot anymore. As such I think the patch should not be part of 
vanilla kernels.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)