Slashdot Mirror
Mark Russinovich on Windows Kernel Security
An anonymous reader writes to mention that in the final part of his three part series, Mark Russinovich wraps up his look at changes made in the Windows Vista Kernel by exploring advancements in reliability, recovery, and security. "Applications written for Windows Vista can, with very little effort, gain automatic error recovery capabilities by using the new transactional support in NTFS and the registry with the Kernel Transaction Manager. When an application wants to make a number of related changes, it can either create a Distributed Transaction Coordinator (DTC) transaction and a KTM transaction handle, or create a KTM handle directly and associate the modifications of the files and registry keys with the transaction. If all the changes succeed, the application commits the transaction and the changes are applied, but at any time up to that point the application can roll back the transaction and the changes are then discarded."
MS made a good move in hiring Russovitch. We can hope that he has more positive influence over kernel changes to XP and Vista than MS has bad influence over things that he does and does not get to say and software (sysinterals) he does or does not get to release.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
For years, the "Registry" was some weird mish-mash of binary files, many of which represented Jet databases.
Has Jet been completed abandoned in Vista?
If so, did they switch to the slimmed down SQLServer [that was supposed to be part of WinFS]?
Because, unlike a DB's transactional system, Vista's is fully pluggable meaning that anything can build volatile transaction management into their application or driver and automagickally gain the benefits of a single logging mechanism and full support for distributed transactions.
And yes, this is a really big deal. Other than maybe OS/400 I know of no system where file system operations can be done atomically with database operations. I can poll data, write a file and update that data all in one atomic operation. Either the data has been exported and marked as such, or not. No in-betweens. No incomplete files. No complete files despite a failure to mark the data in the database. No attempt to manually compensate for errors. It's all there, one operation, atomic and automatically so. This is absolutely massive for my world where financial and business transactions are moved constantly in such a fashion.
Yes, Microsoft does innovate sometimes. This is one of those occasions.
/boot - kernels/initrds I'm not using (which should be tossed out). configs. I don't know what would happen if an insignificant byte in grub.conf changed, but I generally wouldn't bet on being safe. /sbin - oddly enough, lots. fdisk/cfdisk. fsck + friends would probably boot somewhat. e2image, e2label, ctrlaltdel,shutdown,mkfs*,installkernel. /etc - much of it, just to boot. Boot and have everything work, far less of it - but at least I could usually boot and I would usually know what was broken.
/etc, as the one in /etc would generally be in a single plain-text file, and you'd often be able to guess which file from error messages. /sbin and /boot are binary files that don't contain custom configuration data - if something breaks, you can easily replace it without thinking hard. If you lost all of /etc or the registry, you would have to reconfigure your system, which may be far more work.
But yes, I understand your point. However - a broken byte in an unbacked up (yeah a bad idea) registry that causes complete failure is far far harder to find than one in
As the Americans learned so painfully in Earth's final century,free flow of information is the only safeguard against...
I've been known to put my /etc into cvs.
IO commands can be reordered as much as you want, but commands can be tagged for flush or immediate execution, and if a device doesn't comply with those, it is either badly writen or it has incorporated enough safeguards so it doesn't matter.
I'm laughing. No, really. A lot of devices lie in one way or another. It's not just a few badly written devices. You'd be shocked. My favorite are the drives that completely lie and say that the cache has been flushed when it really hasn't. Most of those drives, you can issue a second flush request and it will block, but there are some that always instantly return success for a flush request. It's not even all that uncommon, ESPECIALLY with external drives because of bridge firmware bugs.
I've heard some true horror stories about the number of problems companies find when qualifying off-the-shelf ATA drives for server use. If you heard them, you would cry. Truly, all you can assume is that the operating system has made a best attempt at a guarantee. Anything more than that is just kidding yourself... and you can get that same level of guarantee just as easily from user space (at least in UN*X) by executing two sync system calls in a row.
In addition, how do you expect a user mode component to be able to implement transactional services for kernel components?
WHAT!?!?!?!?!?! Why in you-know-where would anything in the OS kernel need filesystem transaction support? Stuff in the kernel shouldn't even be READING files, much less writing them! Yes, I'm serious. The kernel should provide only the most critical, basic system-wide OS services. Anything that requires such heavy lifting is NOT providing such a critical, low-level service, and thus, does NOT belong in the kernel. It's that sort of thinking that has led to such abominations as khttpd....
I'm going to go hide now. I'm very scared....
Check out my sci-fi/humor trilogy at PatriotsBooks.