Linked by Thom Holwerda on Fri 10th Aug 2007 20:46 UTC, submitted by SReilly
Privacy, Security, Encryption An unpatched flaw in an ATI driver was at the center of the mysterious Purple Pill proof-of-concept tool that exposed a way to maliciously tamper with the Vista kernel. Purple Pill, a utility released by Alex Ionescu [yes, that Ionescu] and yanked an hour later after the kernel developer realized that the ATI driver flaw was not yet patched, provided an easy way to load unsigned drivers onto Vista - effectively defeating the new anti-rootkit/anti-DRM mechanism built into Microsoft's newest operating system.
Thread beginning with comment 262694
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Microkernels
by corentin on Sat 11th Aug 2007 20:03 UTC in reply to "RE[3]: Microkernels"
Member since:

"Besides, it's not like we don't have massively powerful systems that can mask the latencies by sheer power alone."

Take this with a grain of salt, because I'm far from being an expert, but I think that an important part of the performance impact is due to architecture aspects; today's chips (well, x86 stuff at least) aren't really designed to run micro-kernels (context switches are expensive, no real support for messaging, etc.)

BTW, keep in mind context switches are nothing but waste of energy. Why not minimize them in the first place?

Reply Parent Score: 1

RE[5]: Microkernels
by thecwin on Sun 12th Aug 2007 15:58 in reply to "RE[4]: Microkernels"
thecwin Member since:

As I understand it, though I'm not an expert, x86 does provide hardware context switching but no mainstream operating systems use it because it doesn't save all the registers present (specifically floating point registers) and I think it isn't as fast as one might suspect.

Context switches are a huge waste of energy and recent schedulers are going a long way to try to minimise unnecessary ones while maintaining good interactivity. Work is also being put into ensuring threads don't wake up for no reason. I don't think that x86 makes this easy though. Maybe tasks are unnecessarily granulated into separate processes, particularly in (dare I say it) UNIX style operating systems.

Most operating systems are based around the ideas of a kernel, kernel modules, processes, threads, fibres, libraries. I think that there could possibly be more appropriate types of task than the ones outlined above, and I know research is being done into this sort of thing. Essentially, though, it generally comes down to interactivity vs throughput. If you have a lot of context switches (intelligent or not) you generally have better interactivity but worse throughput. The inverse is true.

Assuming hardware support for message queues and so on, I wonder if there's any work being done on a completely event based operating system where libraries and apps are implemented entirely as services. That would seem to match UI principles. I think hardware generally operates in an event driven mode, so the way that tasks are implemented as "processes" with context switches would seem to be an inappropriate abstraction.

Edited 2007-08-12 16:03

Reply Parent Score: 1

RE[6]: Microkernels
by Morin on Mon 13th Aug 2007 11:38 in reply to "RE[5]: Microkernels"
Morin Member since:

About the completely event-based OS: You would still want to isolate work into different "processes" such that bugs or malicious code won't hose the whole system (except for systems in which you can exclude both, but that would only be possible in embedded devices or similar custom systems). That means you get one event handler thread per process. Then some processes would want to do background work - this can be done on an event basis, but this is usually hard to implement since you'd fiddle around with events just to re-create the concept of a background thread. Soon you're back to the old model.

Singularity and JNode wil bring an interesting twist to the whole scene since they don't require context switches at all. But even JNode (don't know about singularity) is all the old model when it comes to concurrency and the likes. Making it completely event-based would bring up other questions, such as: what if an event handler locks up? May another handler be run concurrently, and if so, what about synch locks?

Reply Parent Score: 2

RE[5]: Microkernels
by Morin on Mon 13th Aug 2007 11:24 in reply to "RE[4]: Microkernels"
Morin Member since:

The situation is a lot more complex. First, context switches waste time in different actions (state saving and restoration, process management overhead, cache/tlb misses, etc.) that all have to be considered independently. This is further complicated by the fact that IPC mechanisms in a microkernel can be implemented in a lot of ways (for example, remote procedure calls can be implemented without thread switching, thus saving time).

Secondly, microkernels do not need to do context switching as often as usually claimed, *provided* that programmers get used to asynchronous system requests. If several system requests do not depend on each other's results, they can all be issues with only a single context switch (or at least, a number of context switches equal to the number of targeted service processes).

Third, one has to consider that even microkernels aren't the blue sky. While claimed to be much easier to use as a developer, microkernels produce nondeterministic behaviour between the different service processes. Stallman once talked in a speech about this problem and how it was one major issue with HURD. If there is any one argument that I could bring up against microkernels, then it's this one. It's not an unsolvable problem, but a really hard one. However, it assumes that the processes in a microkernel run concurrently, which is by no means set in stone (remember remote procedure call based IPC).

To sum it up, there is no such thing as "the" microkernel. Saying that microkernels are faster, slower, more secure, less secure, or whatever simply ignores that microkernels themselves are a huge range of possibilities, and much of that is still research area.

Reply Parent Score: 2