Hi everybody, please check some patches for fat*.c at: www.coli.uni-saarland.de/~eric/fatsecurity-updates.diff.gz
For convenience, you can find a compiled kernel and the fat*.c at: www.coli.uni-saarland.de/~eric/fatsecurity-updates.zip I made the patches because somebody mailed me that whenever he gets an unwanted reboot while files are open in certain states on his embedded DOS data logger, he gets cross linked files later. He cannot teach his users to shut down FreeDOS nicely and he cannot always close the file between writes... My changes focus on the most lowlevel FAT processing of DOS, and I added a pile of comments both for old and new code. Here is a tech overview of the fattab / fatfs changes in the patch: - always check if link_fat returns an error (was: never :-p) and try to do something useful on error (abort stuff)... - modify link_fat to trap more invalid input values and improve the "run CHKDSK..." warnings of link_fat and next_cluster - modify next_cluster to do on the fly consistency checks Now next_cluster reads up to 1 slot more, but thanks to BUFFERS, the performance impact is mostly limited to CPU - use a simplified next_cluster function "is_free_cluster" when scanning for / counting free clusters, to avoid the abovementioned performance impact. Using next_cluster instead would check chains for breaks as side effect :-p - review all link_fat calls to see from which to which value category a FAT entry is supposed to change where. Usually, the existing code already ensured a sane context anyway... - write the newly allocated slot before making the previous slot (or if file was empty: the dir entry) point to it in extend() FAT updates: Better lost than dangling chains ;-) - typically also check for FREE whenever checking for ERROR when trying to follow an existing chain, to prevent falling off a chain and to prevent walking around/into in a vacuum - flush buffers after chain shrinks but not after delete/grow (more flushes help with stability but otoh hurt performance) - avoid marking BUFFER with FS INFO disk sector as dirty if it did not really change... Each FAT write tries to update the FS INFO because we have no explicit periods during which it is "unknown". Suggestions for start/end points are welcome. - trap error condition where we try to grow a file at any other point than the end - this could conceivably happen when FAT chain length and file size info mismatch and it could create lost chains and other weird things... ;-) The patched kernel is ca 100 bytes (UPXed) bigger than the previous (9/2007) version and should have similar disk load as the previous version in most situations. Only CPU load is expected to go up notably, in particular for seeks and file size changes. Yet I expect the bottleneck to stay on the disk side even for slow CPUs, so no problem :-). Please have a look and comment. Unless there are bad issues with performance, I would like to add all changes to the official upcoming FreeDOS 2038 kernel. It might be okay to reduce checks again which can only trigger if you break the FS at exactly the wrong SHORT moment. As said, without the patch, "wrong moment" is too long: "boot while file open". Thanks :-) Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-kernel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
