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 262674
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Microkernels
by Flatland_Spider on Sat 11th Aug 2007 18:58 UTC in reply to "RE[2]: Microkernels"
Flatland_Spider
Member since:
2006-09-01

I do like true microkernels, and I think that people should persevere with them and try to work out their inherent performance difficulties.


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

Reply Parent Score: 1

RE[4]: Microkernels
by corentin on Sat 11th Aug 2007 20:03 in reply to "RE[3]: Microkernels"
corentin Member since:
2005-08-08

"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:
2006-01-04

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[5]: Microkernels
by Morin on Mon 13th Aug 2007 11:24 in reply to "RE[4]: Microkernels"
Morin Member since:
2005-12-31

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