Mark Russinovich on Windows Kernel Security 181
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."
doesn't belong in the kernel (Score:4, Insightful)
Re:Not dupe, but almost (Score:5, Insightful)
He's working at Microsoft now, you do realize that "what could be improved" he's actually doing right now, so he can call it "already been done".
You don't really prefer pointless critique with no improvement, do you.
Kernel enhancements? Are you sure? (Score:2, Insightful)
"Requires Ktmw32.dll."
Why would a kernel add-on require a
Re:doesn't belong in the kernel (Score:3, Insightful)
Re:Not dupe, but almost (Score:4, Insightful)
Fresh blood always brings fresh perspectives. Mark has been on the outside looking in for long enough that he probably has a fairly asymetrical view of the NT kernel to that of the core MS developers, and in software development (especially at that level) that tends to be extremely useful.
Not exactly "error recovery" (Score:5, Insightful)
Not exactly most people's idea of robust and recoverable.
'Protected Processes' and PC games (Score:5, Insightful)
With the huge amount of popularity this approach seems to have (I personally suspect it's a result of some very, very aggressive marketing on the part of the driver's developers), I wouldn't be suprised to see many games start demanding that users run them on Windows Vista, so that the 'protected process' mechanism can be used to fully 'protect' the games from users' interference. While you'd at least be able to end-task them, I can't say I see this as an improvement. It's saddening that many companies believe the solution to security is a series of hacks, workarounds, and black boxes - the only real solution is careful, methodical design and engineering. It seems very likely to me that within a few years, many PC games will refuse to run on anything except a Vista system with nothing but signed drivers loaded, and that's saddening. I dislike the notion that I am denied even basic rights to investigate what an application is doing on my machine simply for the sake of 'security', when it's trivial to set up a second machine to inspect and modify a game's network packets and cheat all I want.
Re:doesn't belong in the kernel (Score:5, Insightful)
For instance, how does a user-mode controlled file-system transactions rollback changes on reboot? Consider what happens when the change involves system files. NTFS handles this cleanly in Vista but any attempt to do this with a user-mode service would fail because the system files would already be in-use by the time the service started. Further, any transactions in-doubt would remain in-doubt until the service started (if you could get that far).
Similarly, what about settings in the registry? Consider if the transaction spanned installing a driver and updating its settings. What happens if the system powers down midway through that update? Without kernel-level transactions that are available at boot-time you cannot easily recover before inconsistent settings are used with the driver.
Beyond the boot-level support; another exciting aspect about the KTM is that this is a transaction-manager that provides transactions that can be shared across multiple processes. Try that with a user-mode transaction manager like XA or DTC and see your per transaction performance. By managing the transaction in the kernel, the 2PC performance is significantly improved.
In the end, NTFS and the registry live in the kernel -- so their tramsaction manager also has to live in the kernel. That is just the way it works.
Another exciting aspect covered is the ability to coordinate DTC transactions with KTM transactions. Meaning, you can coordinate your SQL Server (or Oracle) updates with your file-system updates. This is cool! No longer do you have to worry about finding orphan-files in workflow applications or other applications that manage both files and relational data.
Lastly, they are talking about full ACID properties with NTFS's transactions. Think about it -- you could update every file on your web server, in place, while its wild with activity. All your changes are isolated from the users until you say "commit" in your application.
Re:'Protected Processes' and PC games (Score:4, Insightful)
Outside of some very specific gov't spooks contract work, no one is willing to adopt the other because it's more expensive and requires more thought and risk than the average PHB can handle.
Case in point: The number of cashless casino gaming systems that are centrally managed. The average casino manager understands their casino systems are a single, massive, point of failure. Just wait till they go to cashless floors and someone engineers a jackpot for themselves.
Security programming is hard. Really hard. The developers at these companies may _want_ to do the right thing, but they don't because of the complexity and limited resources.
The big-digital-bank-robbery just hasn't happened yet.
Re:Not exactly "error recovery" (Score:5, Insightful)
The format of the registry is largely irrelevant, but it is described to some extent in the "Inside Windows xxx" series of books (which Russinovich co-authored)
Which specific byte would you "scrozzle" in the registry to render a machine unbootable? How and why would you do it?
Extra credit:
Which files under
There are things to like or dislike about either a registry based approach (opaque data storage with a defined interface) vs a flat text based approach (clear data storage with an undefined interface). I don't think you make a compelling "anti-registry" argument with the points you list, however.
Re:doesn't belong in the kernel (Score:2, Insightful)
Yes, I realize that.
And the preprocessor directives are part of that language. Or perhaps you missed sections 5.1.1 and 6.10 of the description [open-std.org] of that language? (Assuming the numbering stayed the same from draft to final.)
Re:Not dupe, but almost (Score:4, Insightful)
Re:I've seen that before... (Score:2, Insightful)
Yes, DBs do. But traditionally file systems don't. The only other system that provides this that I know of that isn't a full-fledged database is VMS.
Re:Not exactly "error recovery" (Score:3, Insightful)
What you've said is correct, the gp's gripe is really about using a binary configuration file.. a fairly stupid decision but that is only my opinion.
My argument for flat text (or xml or whatever) over binary, is the same as every argument about the two for the past 5 years, binary is too system specific, reading/writing it is almost always more painful (faster though), reverse-engineering the format is always a much bigger job.
The "defined interfaces" argument doesn't really wash, you can define an interface just as easily for a text file as you can for binary, however with text someone may be able to edit it by hand or write their own interface, with binary this is much more difficult.
I think what it really comes down to is this; If you decided to write a new OS today from scratch and wanted to have a central configuration database (a good idea, as shown by
Re:doesn't belong in the kernel (Score:4, Insightful)
Of course it can. As long as the OS provides atomic I/O operations on individual files, the logic for implementing two-phase commit is the same in userland or in kernel space. For that matter, atomic I/O can be implemented entirely in userspace, as long as the OS provides a mechanism for userspace to find out when the data has actually been written. It's more convenient to put single-file atomic I/O in the kernel, though (or at least in the file system).
That's not an argument for putting it in the kernel.
Re:Not exactly "error recovery" (Score:4, Insightful)
You can't pump V1@grA spam or DDoS packets out of a dead machine, and malware writers are definitely in it for the cash nowadays. (IIRC, a large percentage of malware specifically hides in the registry...)
Re:doesn't belong in the kernel (Score:1, Insightful)
The actual innovation is making a Kernel Transaction Manager, along with a resource manager for the filesystem. The KTM means that transactions can be inherited from parent process to child or joined by a cooperating process. Having a transactional filesystem means that all file operations can be all-or-nothing. Power goes out during a major update? No problem, because when you boot up again the filesystem will be recovered and it will be like the update was never started. And the beauty of having the resource manager in the filesystem is that you can combine the filesystem transactions with any other ones in the system (via the DTC). In fact, they could even make it so that you can combine transactions across systems so that moving files from one server to another would be atomic.
dom
Re:Not exactly "error recovery" (Score:4, Insightful)
Difference being you're not supposed to modify things in /boot and /sbin for all your settings, and /etc is text and therefore much harder to screw up. (you could put an EOF as the first byte in the file, but the system will still probably at least give you a "file x is empty" error message).
Users aren't supposed to modify the Registry, either.
What you've said is correct, the gp's gripe is really about using a binary configuration file.. a fairly stupid decision but that is only my opinion.
It was designed in the late '80s (well, arguably the late '70s) when a 20Mhz 386 with 4MB of RAM was "bleeding edge". Text-parsing is expensive.
I think what it really comes down to is this; If you decided to write a new OS today from scratch and wanted to have a central configuration database (a good idea, as shown by /etc), would YOU come up with the windows registry?
Windows NT wasn't designed today, it was designed in the late 80s.
Re:Not exactly "error recovery" (Score:3, Insightful)
what is the comment convention?
What is the whitespace convention?
Does this version of this flavor use spaces or tabs in
What are the file locking semantics?
Which set(s) of files are logically related to the same peice of functionality?
What character encodings are supported?
What _line termination_ is supported?
nfs export your
Have you ever done a *nix upgrade on a machine? What happens to most of the files in