Page 3 of 4

Posted: Tue Oct 16, 2007 8:23 am
by Colonel Kernel
MessiahAndrw wrote:Think along the lines of an MSIL processor?
MSIL is too abstract to be executed directly on hardware. Java bytecode however, is not. It doesn't matter anyway, because you can still have unsafe code even in intermediate languages such as these. This is what C#'s "unsafe" blocks compile down to. Safe code is that which as been verified as such.

If someone manages to invent a type system that can express any kind of memory management activity, plus low-level things like interrupt handling, then maybe you can have an entirely type-safe kernel... However, I think this is unlikely simply because it's more cost effective to use code reviews and testing to find bugs in a kernel, if it's small enough. Type-safe GC will probably become a reality though...

Posted: Wed Oct 17, 2007 12:56 am
by AndrewAPrice
Colonel Kernel wrote:
MessiahAndrw wrote:If someone manages to invent a type system that can express any kind of memory management activity, plus low-level things like interrupt handling, then maybe you can have an entirely type-safe kernel...
This may be possible. Like if you had to register events (C# programmer will know what I'm talking about), e.g.

Code: Select all

MySystem.InterruptCalled += InterruptCalled(InterruptCalledEventArgs e);
The processor would have an instruction for registering system event.

Posted: Wed Oct 17, 2007 5:05 am
by Avarok
:D Not only that, but can you imagine how incredibly bad the security and performance of a Microsoft CPU would inevitably be?

The very sentence makes me think a joke is coming.

There is no need for a MISL processor ...

Posted: Sat Oct 20, 2007 12:55 am
by DeletedAccount
But there is no need for such a thing ... coz the il code is converted
to native code before execution ...

Recently got a copy of Microsoft Academic Resource kit .... I am in the process of reading and compleating the given projects ...


But i somehow liked concept of secure multiplexing of resources
by hardware ....

Posted: Mon Oct 22, 2007 6:17 am
by Avarok
:? Unless the conversion is happing JITC, I don't see how one could secure it against spoon-fed bad code. If it is JITC, it'll be much slower to start programs, especially if you're profiling it for performance and security and compiling.

I suppose beyond that, cryptology and the compiler are your only security limitations. Once the program was running it could actually be run in Ring 0 and without security or nearly as many debugging checks (you got those during compilation right?)

Hmm... /me ponders.

Nope. Not good enough. I think you should make the profiler and compiler work on native code and take the IL out altogether. Then you've got yourself a sweet system... (identity mapped semantics means it's as capable as it can be, and there's no hideous obfuscation)

So.. a native profiler/compiler/installer + crypto = security?

Posted: Mon Oct 22, 2007 10:49 am
by Colonel Kernel
Avarok wrote::? Unless the conversion is happing JITC, I don't see how one could secure it against spoon-fed bad code.
The only difference between verifying code in a JIT compiler and verifying it when generating a native binary ahead of time (e.g. -- what ngen does) is when the verification happens. JIT is not a requirement for such a verification scheme.

Posted: Wed Oct 31, 2007 6:36 pm
by Avarok
Precisely.

Except if you compile code and only do your checks on compilation, I can inject code onto your platform while it's not running. A JITC environment is immune to that attack.

The extent of verifying the code hasn't been tampered with involves having and hiding some checksum value, but it's been proven time and again that any hacker worth two cents can figure out and forge/bypass such a system.

Then again, attacks while the platform isn't running is a consideration well beyond what current Operating Systems do. I tend to think disks should be secure beyond the scope of a running OS though.

Posted: Wed Oct 31, 2007 6:59 pm
by Colonel Kernel
Avarok wrote:Precisely.

Except if you compile code and only do your checks on compilation, I can inject code onto your platform while it's not running.
If you want to get really paranoid, I can think of two ways to solve this problem. First, have the system store native binaries in a special directory that is only accessible to the compiler and loader while the system is running. It is basically a cache -- if the IL binary changes, its native image should be deleted. To secure it, all you have to do is keep it encrypted on disk, or flush the cache on each boot-up.

But if you can inject your own code into someone's system while it's not running, it means you have physical access to the hard disk, in which case that person has a much bigger security problem than the OS they're running...

Posted: Thu Nov 01, 2007 5:49 am
by Avarok
:shock: heh..

if you can write to disk, that's a security problem. It doesn't mean you're 100% compromised though. The question is whether you can *read* from it. For example, if I have secret stealth fighter plans on my computer, and you can write over it, I don't care. As long as you don't get the plans. Well, you can even get the plans, as long as they're in an encrypted block with Beale ciphered parts and random garbage over 500Gb long.

Also, if you do write to it, I need to be able to recognize that you've done so, and that the data is therefore compromised (ala checksum).

But agreed, if someone has disk i/o access, you've got a big problem.

Posted: Thu Nov 01, 2007 6:37 am
by Solar
Avarok wrote:if you can write to disk, that's a security problem. It doesn't mean you're 100% compromised though.
For all practical purposes, it does (assuming that "write to it" means non-destructive, i.e. following the rules of the file system, and outside of the supervision of a running security system inherent in your OS). Even if your data cannot be read for the moment, the malicious write might have introduced everything from key sniffer over trojan to a full root kit. The next time you access your encrypted data, you have handed it to the intruder on a platter. All he needs is either a network connection (to have his malware send the decrypted data to him) or another go at physical access (retrieving the copied data from some cache created by his malware).

I grant you that there are ways around each of these attack vectors, but it's better to assume that a write to your disk breaches security.
Also, if you do write to it, I need to be able to recognize that you've done so, and that the data is therefore compromised (ala checksum).
Called intrusion detection. This should go beyond mere checksums. First line of defense should be a physical ID, i.e. a way to tell that someone had access to your system (before you boot up the first time). If you can't have that, everything beyond that isn't secure anymore (as the software ID you might have in place might have been hacked).
But agreed, if someone has disk i/o access, you've got a big problem.
If we talk industry-level security, indeed. For the layman, what we're discussing here is a bit over the top anyway - I estimate the percentage of machines employing any kind of encryption to be in the low one-digit range...

Posted: Fri Nov 02, 2007 9:58 pm
by rv6502
I'm a bit late in the discussion but, an exokernel is not a OS per say.

it is a bunch of libraries that you use to make a single application that runs more-or-less directly on the hardware, so that the application itself is the core and the "OS" is around the application but without the application it is just an empty shell.

an exokernel by itself does not work, it offers functionalties to the application programmer so that he can easily build an application.
things such as multitasking, memory management, file I/O, video output routines, etc, are provided inside the exokernel, but it is up to the application programmer to call and use these.

you can take an exokernel, and make an application that turns into a full fledged OS by using the functionalities of the exokernel and loading sub-applications (the application itself combine with the exokernel, becoming a micro or monolithic kernel)

exokernels are usually designed for single purpose devices, they are often used in video game consoles, where they provide hardware abstractions but leave full control of the machine to the application (game engine) programmer.

they often give you ready-to-use thread and fiber handling routines, sound input/output and video control API, storage device API, a bsd-like socket networking layer, but its up to you to plug them all together and use them properly.

if you take the linux kernel, remove the "init" process, and keep just the interrupt and hardware handling part, you get an exokernel.
something totally useless until you put some application in the center (the "init" process) that puts it in movement.

Posted: Sat Nov 03, 2007 7:57 am
by Combuster
rv6502 wrote:I'm a bit late in the discussion but, an exokernel is not a OS per say.
A kernel is only part of the os. That isn't exokernel-specific.
it is a bunch of libraries that you use to make a single application that runs more-or-less directly on the hardware, so that the application itself is the core and the "OS" is around the application but without the application it is just an empty shell.
Either you're talking about a libOS or you're confusing exokernel-systems with DOS
an exokernel by itself does not work, it offers functionalties to the application programmer so that he can easily build an application.
things such as multitasking, memory management, file I/O, video output routines, etc, are provided inside the exokernel, but it is up to the application programmer to call and use these.
again, the same for e.g. the linux kernel
you can take an exokernel, and make an application that turns into a full fledged OS by using the functionalities of the exokernel and loading sub-applications (the application itself combine with the exokernel, becoming a micro or monolithic kernel)
Whatever runs in userland does not redefine the type of kernel. Even if I delegated all port I/O to root processes under linux, it will still be a modular kernel. It wouldn't suddenly become a microkernel because you can still load drivers into kernel space.
exokernels are usually designed for single purpose devices, they are often used in video game consoles, where they provide hardware abstractions but leave full control of the machine to the application (game engine) programmer.
You're again confusing an exokernel with DOS-style systems. Exokernel do not give full control over the hardware. They give the most possible control that maintains the integrity of the system. The 'kernel' we find on consoles is more along the lines of a BIOS (possibly with a lot more features than the PC bios). It provides services which we might or might not use, but does not at all provide security. Wether the BIOS can be classified as a kernel is open for discussion.
And btw, Xok wasn't a single-purpose exokernel, and neither will mine be.
they often give you ready-to-use thread and fiber handling routines, sound input/output and video control API, storage device API, a bsd-like socket networking layer, but its up to you to plug them all together and use them properly.
the same holds for other kernels - only the interface is different.
if you take the linux kernel, remove the "init" process, and keep just the interrupt and hardware handling part, you get an exokernel.
something totally useless until you put some application in the center (the "init" process) that puts it in movement.
linux is a modular kernel, and it will be that way. it abstracts everything to files rather than low level primitives and can therefore not ever be classified as an exokernel. If you use something other than the init process you will still use the linux kernel, and therefore, be a linux.

Next time, would you please consider your arguments a bit better before posting? :roll:

Posted: Sun Nov 04, 2007 5:06 am
by Avarok
:shock:

Can you guys please read the Xok website or something first. Exokernels don't provide any library. They might provide an interface to someone else's library if they need to.

To clarify, Xok comes with a library (libOS) that was made so that the exokernel could be used, but it's not considered part of the exokerenel.

An exokernel is an effort to NOT abstract, delegate abstraction and simply multiplex.

Does Exokernel worths as a diplomatic work???

Posted: Sat Nov 24, 2007 10:00 am
by louvros10
Hi everyone,
I 'm an undergraduate student and I 'm thinking of doing a diplomatic work on Exokernels...
Do you think that the subject worths a try???
Do you think that I can do something practical except the theory???

Re: Does Exokernel worths as a diplomatic work???

Posted: Sat Nov 24, 2007 11:01 am
by Combuster
louvros10 wrote:I 'm an undergraduate student and I 'm thinking of doing a diplomatic work on Exokernels...
Do you think that the subject worths a try???
There is a lot to say about them, so maybe yes
Do you think that I can do something practical except the theory???
Wouldn't that be your job to find out? (hint) :wink: