Cache Kernel and Ring Architectures

[FZR1KG]

Oh, the other thing I should have mentioned because I noticed the development system they used is that this research is from 1994.
That's 20 years ago. While that on it's own means nothing, two groups tried to implement this super duper easy system and both failed.
While I can't be sure I'd be willing to wager it's because the system isn't an O/S and it transfers it's complexity up.

But I have this awesome idea for a new super computer.
It's going to use minimal power, run for days on a single AA battery as it's current draw is less than 2mA at 100GHz with 16 processors.
As a proof of concept, I already have the AA battery.
I checked and I can show definitively that it will supply power at 2mA for a few days.
If anyone needs proof that a AA battery can still hold power after being discharged at 2mA for a few days, please ask for my research papers.
We are starting licencing for this technology at $1,000,000. Get it now. Limited numbers only.

[Sigma_Orionis]

Which two groups? if you mean the Freedows folks and related?, from what I hear they never got to the point of actually writing code, they had so much political infighting they never got down to do actual stuff, let alone even write a prototype.

These Stanford dudes claim to have done an implementation on an OS called V++ I'm looking for dirt on it.

Ah, here are some numbers on the V++ OS

[Sigma_Orionis]

Here's something that seems another implementation of the subject:

The KeyKOS® Nanokernel Architecture

It predates the Standford stuff, it's from '92

[FZR1KG]

Which two groups? if you mean the Freedows folks and related?, from what I hear they never got to the point of actually writing code, they had so much political infighting they never got down to do actual stuff, let alone even write a prototype.

See how bad it was. They went for 6 years and didn't know how to even start! lol

These Stanford dudes claim to have done an implementation on an OS called V++ I'm looking for dirt on it.

Ah, here are some numbers on the V++ OS

looking at it now.

[FZR1KG]

relies on higher-level application kernels to provide policies

That still tingles my spidey sense.

[FZR1KG]

Here's the latest derivation.
You can download it and try it but it's back from about 2000 or so.

http://www.eros-os.org/eros.html

[Sigma_Orionis]

relies on higher-level application kernels to provide policies

That still tingles my spidey sense.

I have to admit it does smell fishy. It has a bad "cooperative multitasking" smell to it.

[Sigma_Orionis]

I might be wrong, but it seems that this Cache Kernel thing is an Exokernel with the added thing of Caching generated handles and address spaces

Notice that it allows the non kernel stuff to access the device drivers almost directly.

Traditionally kernel designers have sought to make individual hardware resources invisible to application programs by requiring the programs to interact with the hardware via some abstraction model. These models include file systems for disk storage, virtual address spaces for memory, schedulers for task management, and sockets for network communication. These abstractions of the hardware make it easier to write programs in general, but limit performance and stifle experimentation in new abstractions. A security-oriented application might need a file system that does not leave old data on the disk, while a reliability-oriented application might need a file system that keeps such data for failure recovery.

One option is to remove the kernel completely and program directly to the hardware, but then the entire machine would be dedicated to the application being written (and, conversely, the entire application codebase would be dedicated to that machine). The exokernel concept is a compromise: let the kernel allocate the basic physical resources of the machine (e.g. disk blocks, memory pages, and processor time) to multiple application programs, and let each program decide what to do with these resources. The program can then link to a support library that implements the abstractions it needs (or it can implement its own).

I'm not so sure I like it either. It's all your fault Zee, you just HAD to play the Midnight Engineer role

[Cyborg Girl]

Umm, I still don't understand this "cache kernel" stuff, but EROS is one I've read about. It uses an object-capability security model.

http://en.wikipedia.org/wiki/Object-capability_model

As I understand it this basically means that
- Access to resources is handled by something like a file descriptor
- The right to use such a descriptor is not practical for a program to fake, e.g. it might be based on public key authentication

IIRC such systems make it much easier to enforce the principle of least privilege. The problem is it's massively incompatible with the way e.g. UNIX programs work. There is an implementation for Linux and BSD:

http://www.cl.cam.ac.uk/research/security/capsicum/

but programs have to support it. So, not so wonderful for desktop security, but maybe good for a microkernel or hypervisor running other OSes on top of it.

(I do wonder a bit about the overhead though. Calculating an unguessable key pair for every available resource has got to be pretty expensive computationally, no?)

[FZR1KG]

Most of the cache type systems seem to be research toys that never went any further. Same as capability systems.
The latter though can be implemented fairly easily but as GJ said, app's need to be written for it.

The exokernel is like a w.t.f. moment in O/S design. I mean seriously, so with all the pressure on secure systems and security and all the know attacks on systems these guys now want to basically give hardware access to the app. That alone should have killed it.
But it gets worse, it means that every app has to now understand the underlying hardware. To maintain any form of compatibility with different hardware it needs to understand all the hardware types. Basically device drivers are out, they are part of the monolithic O/S kernel model.
Now we have thousands of apps each developing their own drivers and having to have multiple drivers for various hardware configurations and all the testing that would involve as well as the total lack of program separation that virtualization gives.
Also, this is the most hardware dependent model of them all. It spits in the eye of any form of compatibility.

Basically they are proposing going back to MS-DOS on purpose. Though maybe re-entrant.
Anyone remember the days when your software package came with multiple video card drivers that you'd have to load for each app?
When you just bought the latest video card and had to wait for the app developers to support it instead of the manufacturer writing driver and all apps now can use it?

I'm starting to wonder if some of these concepts were developed around the time of DOS by people who had no real clue about a real O/S.
Looked at it from that way (total ignorance) it would almost make sense. Where it fails is that the right way to do it has been known for decades before DOS.
Sheesh.

[Cyborg Girl]

... That does sound stupid.

Seems to me we do want more hardware abstraction, not less; seeing as the most common sources of instability on Linux are 3D programs that need direct GPU access (bypassing the display server). That might be the case on Windows too, for all I know.

[FZR1KG]

The problem with Windows is it's too damned complex. Remember the Easter egg flight simulator built into one version? If it's that big that you can't notice a flight simulator in the source code then you've seriously gone beyond what an O/S is meant to be.
The reason it's so complex is they built it on a weak foundation for the sort of thing we are wanting now. Actually even back then people complained about it's lack of vision. I remember, I was one of them.
It was built on MS-DOS, a non re-entrant program dispatch system, not an O/S.
They even at one point said Windows was no longer running on the platform of DOS. IIRC it crashed to a DOS prompt during a presentation of it.

To maintain compatibility with MS-DOS programs, and there are literally hundreds of thousands of programs that rely on the underlying DOS functions, the Windows O/S has to provide that functionality in.
Writing an O/S that has that functionality built in and be a proper O/S is impossible to do unless you run the whole Windows O/S in a virtual PC allowing backward compatibility and new systems to be run concurrently with it.
IOW, the solution to this never ending cycle is to start developing a totally new O/S, from the ground up that has zero, nada, nothing in common with the MS-DOS and Windows setup.
The way to provide compatibility is then to run the Windows stuff in a virtual PC.
Phase out Windows support but leave the Virtual PC support for it, it would be an app nothing more.
A BSD on the virtual PC would have no effect on anything else. Finally a stable PC.

As developers move to the new system less and less reliance will be put on the old but it will still be possible to run it.

As an example, I run Win2K in a virtual PC when I need to run DOS programs to design PCB's.
To fire up the Virtual Win2K PC takes about 20 seconds on my old laptop (HP pavillion). Less time than it would take to boot Win2K on the laptop.
I get full functionality with it. If ever I need it, it's a few clicks away.

One day maybe someone will come to that realisation and earn their $100 million p.a. salary for this brilliant vision.

As it is though, they will regularly keep patching and patching and fixing issues that stem from the initial poor foundation and the system will keep growing and growing.

[Sigma_Orionis]

Well, on WIndows 7 64 bits M$ did drop support for 16 bit executables.

BTW you just screwed up my whole scheme. Now, I'm going to have to fake it with Marketing. DAMN YOU!

[FZR1KG]

What scheme was that?

[Cyborg Girl]

Guys, NTVDM (Windows NT support for 16-bit DOS applications) is virtualized (plus some emulation):

http://en.wikipedia.org/wiki/Virtual_DOS_machine

From what I'm reading it does not allow direct hardware access of any sort, and is mostly (or perhaps entirely) implemented in user space. There was a case where it allowed privilege escalation to SYSTEM but that was a bug.

Re the completely new OS, that's what the deal with Windows 8 and the new API (WinRT) is supposed to be. They're maintaining backwards compatibility with Win32, but gradually phasing it out. Not exactly FZ's idea of relegating all the 32-bit stuff to a virtual machine, but getting somewhere... Too bad they messed up so badly with the Metro GUI, the stuff underneath is supposed to be pretty interesting (e.g. applications run in AppArmor-style filesystem sandboxes by default).

But of course I haven't actually looked at the API docs, so I could be overoptimistic here.

[Sigma_Orionis]

What scheme was that?

My scheme for using you and squid to write the product to make me the next Bill Gates/Steve Jobs so people on linked in would put a picture of me saying "Legendary Programmer"

[Sigma_Orionis]

Guys, NTVDM (Windows NT support for 16-bit DOS applications) is virtualized (plus some emulation):

http://en.wikipedia.org/wiki/Virtual_DOS_machine

From what I'm reading it does not allow direct hardware access of any sort, and is mostly (or perhaps entirely) implemented in user space. There was a case where it allowed privilege escalation to SYSTEM but that was a bug.

Re the completely new OS, that's what the deal with Windows 8 and the new API (WinRT) is supposed to be. They're maintaining backwards compatibility with Win32, but gradually phasing it out. Not exactly FZ's idea of relegating all the 32-bit stuff to a virtual machine, but getting somewhere... Too bad they messed up so badly with the Metro GUI, the stuff underneath is supposed to be pretty interesting (e.g. applications run in AppArmor-style filesystem sandboxes by default).

But of course I haven't actually looked at the API docs, so I could be overoptimistic here.

Yep, seen NYVDM in action, it sucks. anybody who wants to run 16 bit MSDOS code (not only in Linux ) uses DosBox

M$ dropped support for all 16 bit applications on the 64 bit versions of everything beginning with WIndows 7. Yeah, they're trying go get rid of their compatibility curse, but I don't think is going to be that easy.

[Cyborg Girl]

Sadly DOSbox can't run 16-bit Windows binaries, unless you run Windows 3.x on top of it. And yes, I still have some games that are 16-bit Windows applications. (Haven't played them in years though.)

Edit: Also I recall DOSBox being a bit less user-friendly than Win9x. Still, good point there.

[FZR1KG]

Guys, NTVDM (Windows NT support for 16-bit DOS applications) is virtualized (plus some emulation):

http://en.wikipedia.org/wiki/Virtual_DOS_machine

From what I'm reading it does not allow direct hardware access of any sort, and is mostly (or perhaps entirely) implemented in user space. There was a case where it allowed privilege escalation to SYSTEM but that was a bug.

Re the completely new OS, that's what the deal with Windows 8 and the new API (WinRT) is supposed to be. They're maintaining backwards compatibility with Win32, but gradually phasing it out. Not exactly FZ's idea of relegating all the 32-bit stuff to a virtual machine, but getting somewhere... Too bad they messed up so badly with the Metro GUI, the stuff underneath is supposed to be pretty interesting (e.g. applications run in AppArmor-style filesystem sandboxes by default).

But of course I haven't actually looked at the API docs, so I could be overoptimistic here.

I'd say that they are on the right path except the size is way bigger than it should be for what I'm proposing.
Again that would be trying to be compatible with their other stuff.
You can't have a simple system running compatible with a complex one. It makes no sense.
Hence, scrap it, make it all virtual. Run Windows XXX on the virtual machine.
Apps that want that have the complexity in the virtual window but it does not make the underlying O/S complex as it doesn't have to be compatible to it in any way shape or form.
Basically, Windows XXX would be a complicated app, running on a small virtual O/S, nothing more.

[Sigma_Orionis]

Sadly DOSbox can't run 16-bit Windows binaries, unless you run Windows 3.x on top of it. And yes, I still have some games that are 16-bit Windows applications. (Haven't played them in years though.)

Edit: Also I recall DOSBox being a bit less user-friendly than Win9x. Still, good point there.

Yes, I know, I got both 3.1 and 3.11 on Dosbox.

[Sigma_Orionis]

Ok I found some more dirt, again from the standford folks

Either they changed the name "Cache Kernel" to "ExoKernel" or they started again, don't know enough to determine it.

Reading the PDF I found this pearl that will tickle Zee:

Portability, preventing system chaos
– standard soln: interfaces, good programming
Sharing state with buggy/malicious peers
– General soln: layer protection on exokernel
– How: “privileged”/unprivileged libOS code
» protection code ~ 10% of code base
Reconciling greed and global performance
– greed = faster apps = more resources

Somehow, it sounds unconvincing

[FZR1KG]

Dead end subject. The whole premise of, we allow user apps to access hardware and we're more secure too! sounds like a bubbly moron selling snake oil.


Anyway, if you look up rootkits on wikipedia and then search for hypervisor you get this:

Rootkits have been created as Type II Hypervisors in academia as proofs of concept. By exploiting hardware virtualization features such as Intel VT or AMD-V, this type of rootkit runs in Ring -1 and hosts the target operating system as a virtual machine, thereby enabling the rootkit to intercept hardware calls made by the original operating system.[5] Unlike normal hypervisors, they do not have to load before the operating system, but can load into an operating system before promoting it into a virtual machine.

Not that a root kit can load itself as a hpervisor and run the Wondows O/S in virtual space.
That's exactly what I'm suggesting that MicroSoft does deliberately.
The only difference is that they need to write a proper O/S that it runs on. Not too difficult.
You then get security, compatibility, portability and the ability to create a new faster and more robust O/S without any real penalty.

Found because I figured its not that hard to do with modern processors that provide virtualization capability in hardware and, obviously its a security issue so combine the two and you have someone that has already gone a long way into making it work.

[Cyborg Girl]

Hmm. Problem, I think: to start with most programs will be legacy Windows stuff that will have to run in a VM. What happens if that VM gets compromised?

One could use some kind of VirtualBox copy-on-write method to run each legacy program in its own VM, maybe? But that could get very memory intensive. And where does one draw the line on what a program is? A lot of applications (even on Windows) have tons of little executables.

Let the user set up separate VMs for different tasks, like Qubes? IMO that's a disaster in the making. Let users, even really experienced ones, manage the isolation manually and they will eventually drop the ball.

Also there's the problem of filesystem access for legacy programs. I have a bunch of office documents; okay, I can run MS Office in a VM. I give it access to System/Users/GJ/OfficeStuff (or whatever the correct path is on the new OS). A couple weeks later I open a malicious DOC file that wipes out everything accessible from the VM, including the mount point with my precious Office documents. D'oh!

Not saying any of this is a bad idea, mind. It's just that compromised VMs are still a problem, even if the more advanced underlying OS remains impervious.

[FZR1KG]

You're over thinking the problem GJ.

How does one compromise a system that's run in virtual space?
If the entire O/S is in virtual space all it can affect are things relating to it.
So it son't affect another copy of Windows or the copy of Linux etc.

If you're talking about it compromising the windows O/S while in the virtual window, well, that is regardless. It has nothing to do with the underlying O/S.
Basically the Windows O/S is an app and an app can compromise itself, so long as it doesn't affect anyone else.
Anything that runs under that app is still part of the app.

Once you have a new O/S under it however what you have is a new platform that is a lot harder to compromise.

You also have to remember, if there is a way to break out off virtual space and affect the underlying system, then that will easily be fixed as it's an obvious implementation bug. A hell of a lot less chance o that than the thousands that currently orbit cyberspace.

[Cyborg Girl]

Not overthinking IMO, just thinking from a different angle.

http://www.xkcd.com/1200/

The compromise stays in the VM, but if the VM has access to important resources then so does the attacker. I'm basically thinking of a business situation - you have a ton of client data in a database with no support for the new OS, someone wants to break into that database.

Really nasty stuff (keylogging, turning the machine into a Tor exit node, etc.) would be harder (since presumably the new OS is logging network traffic from the VMs). But my point is basically that virtualizing the old OS is only secure if the resources it has access to are unimportant.