OSDev.org

I don't think I understood this correctly.

You trust the package maintainer. How did he prove that his software is not malicious?

The user's system checks the signature of the package. How did the user get the public key of the package maintainer?

I have more questions, but please answer these two first, as the others base on them.

Solar wrote:I don't think I understood this correctly.

You trust the package maintainer. How did he prove that his software is not malicious?

The user's system checks the signature of the package. How did the user get the public key of the package maintainer?

I have more questions, but please answer these two first, as the others base on them.

The software he has signed is open source, and the bytecode is freely readable. Our bytecode is reflective, so it's possible to identify any wrongdoing (including performing escape analysis on the variable that receives the private key, if needed).

Key transfer is a solved problem; look at SSL certificating authorities.

JamesM wrote:

Solar wrote:You trust the package maintainer. How did he prove that his software is not malicious?

The software he has signed is open source, and the bytecode is freely readable. Our bytecode is reflective, so it's possible to identify any wrongdoing (including performing escape analysis on the variable that receives the private key, if needed).

But we are talking about AOT compilations, i.e. you don't get to look at the bytecode, all you have is a executable binary with a signature, which would leave you having to trust the package maintainer.

Or are we talking about different things, and you are referring to JIT with bytecode distribution?

Key transfer is a solved problem; look at SSL certificating authorities.

But it is still easy to mess up the protocol of key transfer. Security protocols are something that interest me, and I still haven't really understood your concept, that's why I'm asking. If you feel this to be inappropriate for this thread, reply by PM.

I'll PM you back tomorrow; going to be busy from now until then.

Solar wrote:You trust the package maintainer. How did he prove that his software is not malicious?

You can't, neither could you trust the VFS server in case a virus modified it and injects it's own code into compiled binaries.

Solar wrote:The user's system checks the signature of the package. How did the user get the public key of the package maintainer?

If it's the kernel's responsibility to provide memory protection (via JIT) then I think it's reasonable for the kernel to be the only one it can trust with the key. I see nothing wrong with exposing an API to get the public key (perhaps a debugger wants to get the native code to disassemble it). The private key could be generated inside the kernel on a per session basis, so even with the kernel's source you couldn't get the key. The trick would be generating a unique seed though so it'll be near impossible to reproduce the key.

I would be thinking about a form of keysharing - You can cut the key in parts and force the key only to be reunited if all parties agree. At system installation time, a public-private key is created. The key is then cut into three parts. One goes to the AOT compiler, where it is integrated. The other goes to the kernel, The third part is stored under the user's password.

Result:
The only thing that could be signing programs is the compiler - it has a part of the key, it never gives it away, it only collects the remaining parts when appropriate.
The kernel, who knows of all applications, knows what program is the compiler, and will only pass his part of the key if it can establish its authenticity (by normal hashing means). The kernel can also protect access to the binaries, and thus hide both his, and the compiler's key while the OS is running.
The third part of the key is the user - which is the one who decides in the end what should be run on the computer, and can use the key to enforce whatever software should be installed.

The only possible leaks here are physical access to the system (where you can extract the keys from ram or disk at an unfortunate time), or a broken (hacked) installation

Security is one hell of a topic.

While the public/private keys are a solution. I really don't think its needed. public keys are used to protect the pipeline over an untrusted transport method (a network). If the AOT compiler is trusted (e.g. part of the kernel or run by root) and its cache is only accessible by trusted software (e.g the kernel). Then it is implied that the cached binary is also trusted to the standard and restrictions the AOT has performed during processing.

If the pipeline is broken between AOT -> Cache -> Kernel and an untrusted source can alter it. Then fix it. If an application has access to memory it shouldn't, then fix the problem in the AOT or the Kernel. =]

The overhead would be huge using public keys.

MikeyB

run in ring 0...that reminds me of me a while back...http://forum.osdev.org/viewtopic.php?t=16529

MessiahAndrw wrote:Thanks, Dex!

earlz wrote:Wait so your building a high performance(Soft Real-Time-ish) OS where the applications run in .Net.. Isn't that like contradicting itself? That's like saying "I'm going to build the most secure OS" and then having all the applications run in ring 0. Sure you can get fast speeds in your OS... as fast as .Net can allow..

.Net doesn't imply slowness, all code is ran natively on the CPU.

.Net implies a kind of garbage collection which is incompatible with real-time requirements.

And there is one compromise way that is too often overlooked, IMHO: Compile-at-installation. You get all the benefits of knowing exactly the hardware layout of the target system, having no performance penalty at load time, and the ability to sign the binary, using a checksum including some hardware values. No unsigned code being allowed to run, means that your installer (the signing authority) can double as a strong anti-virus checkpoint, and (if you are so minded) means that you cannot pack together the binaries on disk and redistribute them elsewhere.

So what you're saying is essentially that when you upgrade your hardware you'll have to recompile all your applications because they're signed and optimized for your old hardware. Nice...

Craze Frog wrote:

And there is one compromise way that is too often overlooked, IMHO: Compile-at-installation. You get all the benefits of knowing exactly the hardware layout of the target system, having no performance penalty at load time, and the ability to sign the binary, using a checksum including some hardware values. No unsigned code being allowed to run, means that your installer (the signing authority) can double as a strong anti-virus checkpoint, and (if you are so minded) means that you cannot pack together the binaries on disk and redistribute them elsewhere.

So what you're saying is essentially that when you upgrade your hardware you'll have to recompile all your applications because they're signed and optimized for your old hardware. Nice...

But it would only break if you changed your processor model (the same model at a different clock speed will work), which is a pretty rare operation due to the limitations of the socket and chipset for using newer processors. It also will never apply to the "user" population, who can barely upgrade RAM - other users can be assumed to know the risks.

Think about it - when people update the circumstances generally improve. x86 legacy will mean it's backwards compatible.

And there's nothing stopping you from recompiling the bytecode when the system changes for the worse. Ever tried a firmware update on a Nokia smartphone? It looks for and reinstalls all software that was present on the device before the update.

Also, if someone upgrades a rather important piece of hardware, usually they expect that the system will have to do some stuff to adapt. Plus, you don't have to update everything all at once, just the things that are actually being used. BFE.exe may never get updated because the user might not ever run it after the upgrade.

Craze Frog wrote:.Net implies a kind of garbage collection which is incompatible with real-time requirements.

You're right in that the garden-variety generational collector found in the CLR wouldn't cut it. However, there are real-time collectors: http://domino.research.ibm.com/comm/res ... oop07.html

The Singularity kernel has a real-time concurrent mark-sweep collector.