[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    [9fans] GSoC 2010 idea: native code signing in Inferno
From:       Nick Frolov <nf () mkmks ! org>
Date:       2010-03-22 0:39:40
Message-ID: 1269218380.2407.187.camel () thinkfree
[Download RAW message or body]

Hi,

Plan9-gsoc @ Google Groups does not look very active, so I'm posting
here.

I'm doing my masters in Computer Engineering at Chalmers (Sweden). I
participate in a project within my department that is called FlexSoC. It
aims to develop a computing platform that is reconfigurable both at
design-time (means, the task of putting custom accelerator blocks to the
chip is highly automated) and run-time (means, the assembler is form of
RTL). Right now we do not have any real OS running on it (only
benchmarks), which limits its use.

Two years ago I've spent some time playing with Plan 9 and Inferno,
mostly with userland and 9P (my motor skills in acme are still intact).
I didn't look deep into kernel internals though. So I have proposed to
create a port of Plan 9 or Inferno for this architecture, as both have
very good functionality/footprint ratio. This work will begin after the
toolchain will be stabilized, but there is something that can both
become a GSoC project and have an outcome that will be interesting for a
larger audience.

Inferno has drawn my attention because it does not require hardware
support for memory protection while still providing full separation of
processes. Also, using just one level of privileges helps to get rid of
lots of context switches for activities that usually require a system
call. But compiling applications for an embedded system to VM bytecode
(with or without JIT enabled) raises many power- and performance-related
questions. This is main source of concern for project members and a
reason to consider Plan 9 over Inferno.

Still, that might be overcome with extending usage of native code in
Inferno. Binaries resulting from JIT- or AOT-compilation (performed
off-device) might be stored between application runs. This raises the
question of trust to these binaries, as without any hardware-enforced
checks it becomes easy for an attacker to mangle the code. It can be
solved by introducing digital signatures and verifying binaries on the
load.

Native code protection is not the only reason why I want to implement
code signing in Inferno. Trusted computing extensions are to be
developed for FlexSoC (this will become my thesis, hopefully), and a
compact OS infrastructure is needed to support them in applications.
Code measurement is one of crucial features of a trusted platform.
Existing Plan 9/Inferno applications can be further improved by running
on a trusted platform, e.g. by protecting factotum's secstore.

Here is my vision of how this project should be carried out:

1) Review security model of Inferno and bring additional classes of
threats to it, as now only user authentication and channel encryption in
9P are covered.
2) Implement storing/loading of JITed native code to/from the disk
3) Implement an offline compiler that will create native binaries
(probably, by exposing some of VM JIT internals to userland)
4) Check, if existing cryptographic framework in Inferno is generic
enough to be easily extended with new algorithms
5a) If not, think of a new (compact) framework and how existing code can
become part of it
6) Check, if existing crypto libraries in Inferno contain any serious
quirks that can block their usage
6a) If there are quirks, fix them
7) Extend code loader to actually perform signature verification

As you can see, the task of kernel measurement at boot time is not
covered here. And it cannot be, because a good solution would require to
have root of trust in hardware, this is not properly implemented in
available commodity processors (will be solved in FlexSoC, though). This
list might look very extensive for some, but in reality it is not. I
have some experience from real life in how a crypto framework should
(not) be implemented or how to show that a system is (not) protected
against specified threats. Details (not many, really) can be read on my
CV (mostly intended to appeal to potential employers):
http://mkmks.org/nick-frolov-cv.pdf

So, now I'd like to receive feedback on this. I hope, there will be
some.


[prev in list] [next in list] [prev in thread] [next in thread]