Linked by Hadrien Grasland on Fri 30th Dec 2011 08:24 UTC
Hardware, Embedded Systems In the world of alternative OS development, portability across multiple architectures is a challenging goal. Sometimes, it may be intrinsically hard to come up with hardware abstractions that work well everywhere, but many times the core problem is one of missing information. Here, I aim at learning more about the way non-x86 architectures deal with CPU IO ports, and in particular how they prevent user-mode software from accessing them.
Thread beginning with comment 501757
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: IO on other platforms
by bartgrantham on Sat 31st Dec 2011 03:32 UTC in reply to "RE: IO on other platforms"
bartgrantham
Member since:
2011-12-31

In a managed language, this wouldn't be a problem, but it is with C/C++ which is what drivers are written in. It's one of the reasons I've been advocating using managed code in the OS for some time.


I've heard this opinion expressed before, but I'm not sure I understand why anyone would feel this way.

What's the effective difference between a VM running in kernel space and a microkernel? Either you're trapping dangerous/unauthorized instructions in hardware or you're doing it in software. I don't really see much advantage to doing it in software except that bugs in that access layer can be updated when they are discovered.

Unless you're advocating something like what Open Firmware had where you could have drivers in bytecode that are cross-architecture compatible, but there's a performance reason why that was only used for bootstrapping and the OS shipped with CPU-specific drivers.

Reply Parent Score: 1

"managed"
by daddio on Sat 31st Dec 2011 04:34 in reply to "RE[2]: IO on other platforms"
daddio Member since:
2007-07-14

Why would anyone have a problem with the word "managed" as used to describe dotnet?

Because there was nothing new there that didn't already exist in other execution environments. They were not considered "managed".

It was PURE marketing.

It wasn't manged any more than java, or heck, interpretted languages like bash or BASIC, which run under the supervision of another process.

Reply Parent Score: 1

RE[3]: IO on other platforms
by Alfman on Sat 31st Dec 2011 05:04 in reply to "RE[2]: IO on other platforms"
Alfman Member since:
2011-01-28

bartgrantham,

"What's the effective difference between a VM running in kernel space and a microkernel? Either you're trapping dangerous/unauthorized instructions in hardware or you're doing it in software. I don't really see much advantage to doing it in software except that bugs in that access layer can be updated when they are discovered."


I'm happy you brought this up, although I'm pretty sure the author would consider this off topic.

There are some well known impediments with traditional micro-kernel designs, which are typically implemented using hardware userspace boundaries, as you observed. I'm sure I don't need to tell you, but I will elaborate anyways:

1. Kernel syscalls are slow, they often involve saving/loading various CPU register states and transferring data between userspace and kernel stacks.

2. IPC between drivers is usually much slower between micro-kernel drivers because data has to be copied from one address space to another. The equivalent operations in a macro-kernel involve simply passing around object pointers since macro-kernel drivers always share the same address space and drivers implicitly trust each other not to clobber the data of other drivers.


It's difficult to do anything to fix #1, we're basically at the whim of intel's engineers. The inefficiency can be measured in the difference in time between a normal function call and a syscall.

There are various things one might do to improve #2. One is to minimise the use of copied byte streams and design the IPC around shared memory instead. I'll let you ponder it, but none of the solutions are ideal.


A custom VM based micro kernel using a managed language would offer a potentially novel solution to both those problems.

Consider that in our managed language, a function can only access objects which it has a pointer/reference to. Even if other objects exist in the same address space, the managed language semantics prevent the function from touching objects for which no reference is available. We can take advantage of this fact by running two or more separate processes in the same address space (using one or more memory allocaters). Since the managed language guaranties that one process can never generate references to objects of the other process, the two processes can not corrupt each other. This achieves perfect process isolation without using hardware modes and without using any syscalls.

Now for IPC, we could designate specially typed references/pointers to guaranty the object pointed to is only referenced once by a process. Then these references/objects could be instantly transferred to the other processes running in the same address space using specialised constructs of the managed language. So transferring objects between drivers is as simple as passing a pointer in the macro-kernel approach.

So in a nutshell, you have microkernel drivers running in isolation under a kernel level VM without using hardware separation, and it doesn't have the overhead traditionally associated with userspace micro-kernels. You'd get all the other benefits of managed code as well, like those you mentioned.

Honestly there's nothing conventional about the micro-kernel approach I've illustrated. It's purely my own opinion and probably has little in common with the reasons others may have had to use VM based kernels.

Reply Parent Score: 2

RE[4]: IO on other platforms
by Alfman on Sat 31st Dec 2011 06:46 in reply to "RE[3]: IO on other platforms"
Alfman Member since:
2011-01-28

bartgrantham,

I wanted to list some other possible optimisations using managed code in a VM based micro-kernel:

3. A traditional micro-kernel with unmanaged code would typically need to validate that all parameters and data structures passed in are of the correct type and pointers are valid, which costs CPU cycles. However with managed code, the correctness of data structures and pointers might be inferred through strict types without checks.

4. It would take a hell of a good code optimiser to pull it off, but conceptually there's no reason the kernel VM couldn't automatically "inline" inter-driver function calls, such that there's *zero* function call overhead between microkernel drivers while keeping security semantics in place. After all, any steps taken by two functions, no matter what they do, could be done in one function instead.

Note: this might already happen with macro-kernel code using -O3, but this would be a very impressive speedup for a micro-kernel which typically requires a couple secure context switches for each IPC request between userspace drivers.

The main point to remember is that none of these microkernel optimisations are securely feasible using unmanaged code and hardware isolation.

Edited 2011-12-31 06:59 UTC

Reply Parent Score: 2

TemporalBeing Member since:
2007-08-22

Consider that in our managed language, a function can only access objects which it has a pointer/reference to. Even if other objects exist in the same address space, the managed language semantics prevent the function from touching objects for which no reference is available. We can take advantage of this fact by running two or more separate processes in the same address space (using one or more memory allocaters). Since the managed language guaranties that one process can never generate references to objects of the other process, the two processes can not corrupt each other. This achieves perfect process isolation without using hardware modes and without using any syscalls.


Except that managed languages do not make those guarantees.

Indeed, even if the language could make that guarantee, you could also use the language to locate the object without being strictly given access to it:

- create a reference to a memory segment to locate the object (e.g. searching memory to find it)
- decode another object that has a reference to it and steal a reference

In either case you were not explicitly granted a reference to the data but achieved it. These are both methods of cracking software, and both are also valid under managed languages.

So using a managed language buys you nothing in the end while costing a lot, in terms of performance

Reply Parent Score: 2