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."
Although this is technically not a dupe, it is almost, as the above linked article is the Part 3 and the other submitted and discussed article was the Part 1, isn't it kinda repetitive? What now, someone post a multipart article and we will get one story here on front page for each part?
On topic now, I don't like the way Russinovich is blowing Vista's horn now. I liked him more when he was more critical and analytical on what could be improved, instead of what has already been done.
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.
I am surprised that no one mentioned the registry should be a CVS revisioning system. Being able to roll back/audit and have full control on what gets to read/write registry should help on security.
/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.