From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Frolov To: 9fans@9fans.net Content-Type: text/plain; charset="UTF-8" Date: Mon, 22 Mar 2010 01:39:40 +0100 Message-ID: <1269218380.2407.187.camel@thinkfree> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [9fans] GSoC 2010 idea: native code signing in Inferno Topicbox-Message-UUID: ee2d458e-ead5-11e9-9d60-3106f5b1d025 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.