linux-kernel - Re: End of FAT directories

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: <20110428132551.GA5701@ucw.cz>
Date:	Thu, 28 Apr 2011 15:25:52 +0200
From:	Pavel Machek <pavel@....cz>
To:	Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>
Cc:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	dosfstools <daniel@...ian.org>, mtools <Alain@...ux.lu>,
	linux-kernel@...r.kernel.org
Subject: Re: End of FAT directories

Hi!

> >  For overwriting the
> > zeroed entry, why we have to check all entries until see next zeroed
> > (yeah, now, we allowed the crappy data after zeroed)?
> My point was not about checking all entries until the next zeroed entry,
> which is overcomplicating stuff. I meant that if we hit the end (i.e.
> the first zeroed entry) when searching for free slots, in that case we
> just clear the one entry directly following the inserted entries. This
> makes sure that no files magically appear. I *do* understand that

This sounds like a good idea, and costs nothing. I hope we can
convince Ogawa...

> In the end, there are two valid interpretations on the problem at hand:
>  - DOS/Windows is buggy in exposing the crap when filling the "hole",
> which is proven by chkdsk not complaining about the garbage in the
> directory, and we should not follow the bug in DOS/Windows
>  - chkdsk is buggy in not complaining about trailing garbage in
> directories, which are proven to be invalid by DOS/Windows messing up on
> them, and we shouldn't complicate our FAT implementation by trying to
> work around a bug in chkdsk.

I believe 2) is the case; but we should still work around that chkdsk
bug.

> I think the *most* important fact is to have at least dosfsck and linux
> consistent about directories with trailing garbage. So I won't even try
> to submit a patch to the Linux kernel that stops reading at the first
> unused directory entry if dosfsck will not accept to stop reading at the
> first unused directory entry.

They should *not* be consistent.

Kernel should stop at zero invalid entry.

fsck should consider any garbage past zero entry as an error, and zero
it out. (Complaining about duplicate blocks is unhelpful but better
than nothing.  It should really zero the garbage out.)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/