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 262812
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Microkernels
by thecwin on Sun 12th Aug 2007 15:58 UTC 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[6]: Microkernels
by Morin on Mon 13th Aug 2007 11:38 in reply to "RE[5]: Microkernels"
Morin Member since:
2005-12-31

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[7]: Microkernels
by baadger on Mon 13th Aug 2007 16:05 in reply to "RE[6]: Microkernels"
baadger Member since:
2006-08-29

> Singularity and JNode wil bring an interesting twist to the whole scene since they don't require context
> switches at all

That isn't quite right. From what I understand Singularity does away with virtual memory (Relying on code verification techniques and managed code to keep things tight) but doesn't regress away preemptive multitasking or get rid of the concept of a context switch.

Reply Parent Score: 1