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? Thanks, Ramya ________________________________________ From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Adam Lackorzynski [a...@os.inf.tu-dresden.de] Sent: 01 September 2014 23:57 To: l4-hackers@os.inf.tu-dresden.de Subject: Re: Checking executables before running them in L4re/fiasco Hi, 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 > >kernel). > > 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 a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
