Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
essial wrote:I personally think VM is the way of the future. With virtual machines running all application code and drivers, security will go through the roof. If an application cannot modify binary data, then there is no excuse for the OS to allow invalid things to take place. For example, the VM application cannot exploit some bug to enject code into the kernel, since all memory operations are done through managed objects with handles.
As far as speed is concerned, I also think that a VM OS would run just as fast, if not faster, than a native OS. Current OS's (Windows and Linux included) are designed around ideas from the 80's, back with 8mb of ram was crazy good, and 300mhz was blazing fast. With 3.4ghz 2-core processors and 2048mb of ram the norm in today's systems, VM should run at seemingly the same speed as a native binary. Ontop of that, the need for antivirus and such will be eliminated, AND of course, the processor's cache doesn't have to reset or flush since you never have to change descriptors.
*end rant*
You are wrong, period. The security won by not allowing VM code inject code in the kernel can mor securely be done by simply write protect the kernel code. I think the MMU is far more likely to be bug free than your VM.
VM code is not as fast as native code. To say that you will get the same speed on a 3GHz dual core running VM code as 300MHz native code is just to say that you don't deserve the extra computing power that you've invested in.
And no you won't need to flush the descriptor tables, but OTOH you will trash the cache running the VM interpreter instead of the code you're trying to execute.
Nick Carlson wrote:Most kernels I've come across are written in C (with the rare c++ exception).
I'm wondering, does any know of any kernels which have been written in other languages? Is it even a possibility? I know there are several factors which play into this (the size of the languages standard library being one).
I'm using assembly. The design concept and the lack of public documentation for different hardware is giving me headaches. With C/C++ and higher languages, people seem to take those for granted, maybe because C is the most widely used language for driver development these days and it has all those common libraries which work out of the box just as soon as malloc is provided.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
skyking wrote:
You are wrong, period. The security won by not allowing VM code inject code in the kernel can mor securely be done by simply write protect the kernel code. I think the MMU is far more likely to be bug free than your VM.
VM code is not as fast as native code. To say that you will get the same speed on a 3GHz dual core running VM code as 300MHz native code is just to say that you don't deserve the extra computing power that you've invested in.
And no you won't need to flush the descriptor tables, but OTOH you will trash the cache running the VM interpreter instead of the code you're trying to execute.
Actually he's not that wrong. A type 1 hypervisor should hold about a 3-4% hardware penalty. A 3Ghz processor would run about as efficiently as a 2.8 Ghz processor to the kernel. Not really anything less then the kernel will already do by abstracting the hardware. Sandboxes can solve issues but are NOT always the way to go. A poorly written sandbox is as exploitable as a poorly written program. Just implementing certain sanity checks by the kernel is a much better way to do it then trying to add an artificial ring. There's a reason why Intel processors have only 4 rings, because anymore doesn't add to security it just adds to obfuscation.
AdHawk wrote:
Actually he's not that wrong. A type 1 hypervisor should hold about a 3-4% hardware penalty. A 3Ghz processor would run about as efficiently as a 2.8 Ghz processor to the kernel. Not really anything less then the kernel will already do by abstracting the hardware.
But then we're talking about executing native code and the protection is handled by using the MMU. You will then still get the penalties associated with memory protection, and you don't get the increased security since software is not expected to be more reliable than the hardware.
