Checking executables before running them in L4re/fiasco
Masti Ramya Jayaram
rmasti at inf.ethz.ch
Tue Sep 2 09:57:03 CEST 2014
Thanks for the suggestions. From what you say, I guess it is best to do something between ned and say vmlinuz. It also makes better sense semantically (the kernel has booted and checks if the application is ok).
Is there a way to accomplish the following:
a. Ned starts up a new process which does some checks and returns "OK/STOP".
b. depending on the value returned by the new process, ned decides to launch/stop vmlinuz.
When I try "roottask moe rom/hello rom/vmlinuz" in the modules.list file, they execute in parallel. Is there a way to make it sequential?
From: l4-hackers [l4-hackers-bounces at os.inf.tu-dresden.de] on behalf of Adam Lackorzynski [adam at os.inf.tu-dresden.de]
Sent: 01 September 2014 23:57
To: l4-hackers at os.inf.tu-dresden.de
Subject: Re: Checking executables before running them in L4re/fiasco
On Mon Sep 01, 2014 at 07:54:02 +0000, Masti Ramya Jayaram wrote:
> Thanks for the suggestion. I have one other constraint: I would like
> to keep trusted computing base (or the amount of security critical
> code as small as possible).
> >From what I understand from http://l4re.org/doc/index.html, the
> >following constitutes the minimal trusted code (which if buggy or
> >compromised by an attacker ruins the isolation properties of the
> a. Whole of fiasco
> b. Sigma0 (the root pager)
> c. Moe (the loader)
> d. Ned (the first loaded program used to bootstrap the rest)
In this setup, yes. Potentially one could have specialized components
that are even smaller.
> The IO server is not really security critical as far as I understood.
> Is this correct?
IO has access to the hardware, so it can do interesting things.
> So I would ideally like to do it even before sigma because if the
> checks fail, I do not want to proceed and it would be ok to do it in
> moe or ned. So could you elaborate on mmap part to map a piece of IO
> memory say in a separate executable after sigma?
If you want to do it so early I suggest doing it even earlier in
bootstrap. There you run on physical memory and can directly access
anything. You're bit limited feature-wise there but for checking some
memory regions (aka the binaries) it should be ok.
Stuffing another binary inbetween sigma0 and moe is not directly easy
and is also quite limited feature-wise.
Adam adam at os.inf.tu-dresden.de
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
More information about the l4-hackers