Re: Checking executables before running them in L4re/fiasco
On Mon Sep 08, 2014 at 07:13:14 +, Masti Ramya Jayaram wrote: > Yes, I explicitly made sure that there are no extra characters by > setting the entire page of 4096 bytes to zero before copying over the > new config. I am not sure what you mean by changed the target - I > simply replace the config file. So I thought it picks up the size > information from the MBI header. With target I meant to memory location after potentially moving the module around, i.e. the final location. At that point the exact size should not really be an issue except when it would cross page boundaries. Does it work if you for example at a couple of newlines at the end of the file? 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
RE: Checking executables before running them in L4re/fiasco
Hey Adam,
Yes, I explicitly made sure that there are no extra characters by setting the
entire page of 4096 bytes to zero before copying over the new config. I am not
sure what you mean by changed the target - I simply replace the config file. So
I thought it picks up the size information from the MBI header.
I will try the MODE option as you mentioned it. I misunderstood it earlier.
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: 08 September 2014 00:03
To: l4-hackers@os.inf.tu-dresden.de
Subject: Re: Checking executables before running them in L4re/fiasco
Hi,
On Fri Sep 05, 2014 at 12:29:15 +, Masti Ramya Jayaram wrote:
> Thanks for the information. I have two issues/questions:
>
> a. I looked at the move_modules (which does not do much in my case) and I
> tried to replace the linux.cfg from
>
> Compiled in version:
> --
> --vim:set ft=lua:
>
> L4.default_loader:start({ caps = {
> log = L4.Env.log:m("rws"),
> },
> l4re_dbg = L4.Dbg.Warn,
> log = { "l4linux", "yellow" },
> }, "rom/vmlinuz mem=128M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
> root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1");
>
>
> Replaced version: (just the memory changes but this results in a difference
> in the length!)
> ---
> --vim:set ft=lua:
> L4.default_loader:start({ caps = {
> log = L4.Env.log:m("rws"),
> },
> l4re_dbg = L4.Dbg.Warn,
> log = { "l4linux", "yellow" },
> }, "rom/vmlinuz mem=64M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
> root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1");
>
>
> I achieve this with the following code that runs immediately after
> construct_mbi:
>
> a. Copy the placed version into the start address of the linux_cfg
> module (this happens correctly as I can see the memory dump).
> b. Change the compressed and uncompressed lengths in mod_info to
> reflect the smaller size.
>
> The process runs until ned which fails to parse the config file
> (unexpected symbol error) and the problem seems to be the difference
> in length of the two configs. For example, if the 2nd config is
> "mem=064M" instead of "mem=64M", then it works. I change the length
> appropriately in mod_info of the mbi. What am I missing?
When you already changed the target, changing the size variables
probably won't make a difference. Did you clear out the old contents? I
think you have remaining characters in the file that are interpreted and
causing the error.
> a. The "MODE = sigma0" suggestion: I tried this by changing
> bootstrap/server/src/Make.rules but I get an error saying: "ld: cannot
> find -ll4util". The relevant part in the linker line that differs from
> the default working build (with "MODE = lib") is:
Wait. I meant the MODE=sigma0 for newly created programs. If you want to
make bootstrap smaller, you need to remove code/features from it.
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
Re: Checking executables before running them in L4re/fiasco
Hi,
On Fri Sep 05, 2014 at 12:29:15 +, Masti Ramya Jayaram wrote:
> Thanks for the information. I have two issues/questions:
>
> a. I looked at the move_modules (which does not do much in my case) and I
> tried to replace the linux.cfg from
>
> Compiled in version:
> --
> --vim:set ft=lua:
>
> L4.default_loader:start({ caps = {
> log = L4.Env.log:m("rws"),
> },
> l4re_dbg = L4.Dbg.Warn,
> log = { "l4linux", "yellow" },
> }, "rom/vmlinuz mem=128M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
> root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1");
>
>
> Replaced version: (just the memory changes but this results in a difference
> in the length!)
> ---
> --vim:set ft=lua:
> L4.default_loader:start({ caps = {
> log = L4.Env.log:m("rws"),
> },
> l4re_dbg = L4.Dbg.Warn,
> log = { "l4linux", "yellow" },
> }, "rom/vmlinuz mem=64M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
> root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1");
>
>
> I achieve this with the following code that runs immediately after
> construct_mbi:
>
> a. Copy the placed version into the start address of the linux_cfg
> module (this happens correctly as I can see the memory dump).
> b. Change the compressed and uncompressed lengths in mod_info to
> reflect the smaller size.
>
> The process runs until ned which fails to parse the config file
> (unexpected symbol error) and the problem seems to be the difference
> in length of the two configs. For example, if the 2nd config is
> "mem=064M" instead of "mem=64M", then it works. I change the length
> appropriately in mod_info of the mbi. What am I missing?
When you already changed the target, changing the size variables
probably won't make a difference. Did you clear out the old contents? I
think you have remaining characters in the file that are interpreted and
causing the error.
> a. The "MODE = sigma0" suggestion: I tried this by changing
> bootstrap/server/src/Make.rules but I get an error saying: "ld: cannot
> find -ll4util". The relevant part in the linker line that differs from
> the default working build (with "MODE = lib") is:
Wait. I meant the MODE=sigma0 for newly created programs. If you want to
make bootstrap smaller, you need to remove code/features from it.
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
RE: Checking executables before running them in L4re/fiasco
Hey Adam,
Thanks for the information. I have two issues/questions:
a. I looked at the move_modules (which does not do much in my case) and I tried
to replace the linux.cfg from
Compiled in version:
--
--vim:set ft=lua:
L4.default_loader:start({ caps = {
log = L4.Env.log:m("rws"),
},
l4re_dbg = L4.Dbg.Warn,
log = { "l4linux", "yellow" },
}, "rom/vmlinuz mem=128M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1");
Replaced version: (just the memory changes but this results in a difference in
the length!)
---
--vim:set ft=lua:
L4.default_loader:start({ caps = {
log = L4.Env.log:m("rws"),
},
l4re_dbg = L4.Dbg.Warn,
log = { "l4linux", "yellow" },
}, "rom/vmlinuz mem=64M console=ttyLv0,115200 l4x_rd=rom/ramdisk-x86.rd
root=1:0 ramdisk_size=4000 l4ser.vkey_enable=1");
I achieve this with the following code that runs immediately after
construct_mbi:
a. Copy the placed version into the start address of the linux_cfg module (this
happens correctly as I can see the memory dump).
b. Change the compressed and uncompressed lengths in mod_info to reflect the
smaller size.
The process runs until ned which fails to parse the config file (unexpected
symbol error) and the problem seems to be the difference in length of the two
configs. For example, if the 2nd config is "mem=064M" instead of "mem=64M",
then it works. I change the length appropriately in mod_info of the mbi. What
am I missing?
a. The "MODE = sigma0" suggestion: I tried this by changing
bootstrap/server/src/Make.rules but I get an error saying: "ld: cannot find
-ll4util". The relevant part in the linker line that differs from the default
working build (with "MODE = lib") is:
==> Linking bootstrap.elf
..
-Tbootstrap.ld --start-group -ll4util -ll4sys -luc_c -static -nostdlib
-ldrivers_uart -lcxx_base -lcxx_io -luc_c
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/32/libgcc.a --end-group --warn-common
-Ttext=0x2d /usr/lib/gcc/x86_64-linux-gnu/4.4.3/32//crtend.o
/home/rmasti/fiasco/r33-new/src/l4/build/lib/x86_pentium/crtn.o
The linker line with "MODE = lib" (the difference seems to be that l4util,
l4sys, etc are not really there in the commandline)
==> Linking bootstrap.elf
..
-Tbootstrap.ld --start-group-static -nostdlib -ldrivers_uart -lcxx_base
-lcxx_io -luc_c /usr/lib/gcc/x86_64-linux-gnu/4.4.3/32/libgcc.a --end-group
--warn-common -Ttext=0x2d /usr/lib/gcc/x86_64-linux-gnu/4.4.3/32//crtend.o
/home/rmasti/fiasco/r33-new/src/l4/build/lib/x86_pentium/crtn.o
Why does this happen? What is the relevant modules.list entry for this mode?
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: 05 September 2014 00:39
To: l4-hackers@os.inf.tu-dresden.de
Subject: Re: Checking executables before running them in L4re/fiasco
││ │
│ ││ │
│ ││ │
│ ││ │
│ ││ │
│ ││ │
│ ││
On Wed Sep 03, 2014 at 14:43:59 +, Masti Ramya Jayaram wrote:
> >You mean binaries that are started?
> Yes but some modules have dependencies (like the Io server and
> examples of target dependencies include libsigma). Is there a way to
> find all of them?
Ok, you mean all the libraries that are linked to a program. One way to
find that out is to build the program with "make V=1", see the linker
step and look for all the -lxxx options. The lib directory in the build
tree has all the libraries and those are links to the actual package
directory so you see the package there.
> Finally, on a related note, could you explain to me how all the
> modules get merged to create the elfimage? I ask because I have to
> access the modules (vmlinux, l4linux.cfg and ramdisk) from bootstrap
> in order to modify/check them. For example, I would like to load the
> modules encrypted and decrypt them in bootstrap before continuing. I
> can do decryption in place but again, I am not sure about module
> sizes, etc.
>
> I see that some of this information is included during the image
> creation process in l4/pkg/bootstrap/server/src/build.pl but I cannot
> quite get the entire picture. Could you point me to any documentation
> about it?
In bootstrap, there's
Re: Checking executables before running them in L4re/fiasco
On Wed Sep 03, 2014 at 14:43:59 +, Masti Ramya Jayaram wrote: > >You mean binaries that are started? > Yes but some modules have dependencies (like the Io server and > examples of target dependencies include libsigma). Is there a way to > find all of them? Ok, you mean all the libraries that are linked to a program. One way to find that out is to build the program with "make V=1", see the linker step and look for all the -lxxx options. The lib directory in the build tree has all the libraries and those are links to the actual package directory so you see the package there. > Finally, on a related note, could you explain to me how all the > modules get merged to create the elfimage? I ask because I have to > access the modules (vmlinux, l4linux.cfg and ramdisk) from bootstrap > in order to modify/check them. For example, I would like to load the > modules encrypted and decrypt them in bootstrap before continuing. I > can do decryption in place but again, I am not sure about module > sizes, etc. > > I see that some of this information is included during the image > creation process in l4/pkg/bootstrap/server/src/build.pl but I cannot > quite get the entire picture. Could you point me to any documentation > about it? In bootstrap, there's a move_modules() function that iterates over all the modules and should show you how how to do that. 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
RE: Checking executables before running them in L4re/fiasco
>For a start, you can set "MODE = sigma0" in the Makefile to get a much
Ok, I will try the MODE=sigma0.
>You mean binaries that are started?
Yes but some modules have dependencies (like the Io server and examples of
target dependencies include libsigma). Is there a way to find all of them?
Finally, on a related note, could you explain to me how all the modules get
merged to create the elfimage? I ask because I have to access the modules
(vmlinux, l4linux.cfg and ramdisk) from bootstrap in order to modify/check
them. For example, I would like to load the modules encrypted and decrypt them
in bootstrap before continuing. I can do decryption in place but again, I am
not sure about module sizes, etc.
I see that some of this information is included during the image creation
process in l4/pkg/bootstrap/server/src/build.pl but I cannot quite get the
entire picture. Could you point me to any documentation about it?
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: 03 September 2014 00:02
To: l4-hackers@os.inf.tu-dresden.de
Subject: Re: Checking executables before running them in L4re/fiasco
On Tue Sep 02, 2014 at 14:08:03 +, Masti Ramya Jayaram wrote:
> Also, could you elaborate a bit on how one could have smaller
> components? I decided to do it at bootstrap at the moment because I
> realized that using the IO server also means including the entire C
> library (and much more).
For a start, you can set "MODE = sigma0" in the Makefile to get a much
simpler setup (don't be confused by the name). Of course, not all
features are there then but should be ok for checking a binary. More
libraries can be removed further but also requires to do more by hand
then.
> On a related note, is there a way to find all the packages in use
> (there is more than what is compiled by module.list I can see)?
You mean binaries that are started? modules.list has defaults for
kernel, sigma0 and roottask but otherwise everything else needs to be
put there.
>
> From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Masti
> Ramya Jayaram [rma...@inf.ethz.ch]
> Sent: 02 September 2014 09:57
> To: Adam Lackorzynski; l4-hackers@os.inf.tu-dresden.de
> Subject: RE: Checking executables before running them in L4re/fiasco
>
> 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?
You start ned via moe (as usual) and have a script like this:
local l = L4.default_loader;
local e = l:start({}, "rom/checker rom/hello");
if e:wait() == 0 then
l:start({}, "rom/hello");
else
print("Something is wrong with hello.");
end
So the checker program does exit(0) or exit(1) depending on its result.
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
Re: Checking executables before running them in L4re/fiasco
On Tue Sep 02, 2014 at 14:08:03 +, Masti Ramya Jayaram wrote:
> Also, could you elaborate a bit on how one could have smaller
> components? I decided to do it at bootstrap at the moment because I
> realized that using the IO server also means including the entire C
> library (and much more).
For a start, you can set "MODE = sigma0" in the Makefile to get a much
simpler setup (don't be confused by the name). Of course, not all
features are there then but should be ok for checking a binary. More
libraries can be removed further but also requires to do more by hand
then.
> On a related note, is there a way to find all the packages in use
> (there is more than what is compiled by module.list I can see)?
You mean binaries that are started? modules.list has defaults for
kernel, sigma0 and roottask but otherwise everything else needs to be
put there.
>
> From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Masti
> Ramya Jayaram [rma...@inf.ethz.ch]
> Sent: 02 September 2014 09:57
> To: Adam Lackorzynski; l4-hackers@os.inf.tu-dresden.de
> Subject: RE: Checking executables before running them in L4re/fiasco
>
> 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?
You start ned via moe (as usual) and have a script like this:
local l = L4.default_loader;
local e = l:start({}, "rom/checker rom/hello");
if e:wait() == 0 then
l:start({}, "rom/hello");
else
print("Something is wrong with hello.");
end
So the checker program does exit(0) or exit(1) depending on its result.
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
RE: Checking executables before running them in L4re/fiasco
Also, could you elaborate a bit on how one could have smaller components? I decided to do it at bootstrap at the moment because I realized that using the IO server also means including the entire C library (and much more). On a related note, is there a way to find all the packages in use (there is more than what is compiled by module.list I can see)? Thanks, ramya From: l4-hackers [l4-hackers-boun...@os.inf.tu-dresden.de] on behalf of Masti Ramya Jayaram [rma...@inf.ethz.ch] Sent: 02 September 2014 09:57 To: Adam Lackorzynski; l4-hackers@os.inf.tu-dresden.de Subject: RE: Checking executables before running them in L4re/fiasco 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 +, 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 ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
RE: Checking executables before running them in L4re/fiasco
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 +, 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
Re: Checking executables before running them in L4re/fiasco
Hi, On Mon Sep 01, 2014 at 07:54:02 +, 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
RE: Checking executables before running them in L4re/fiasco
Hey Adam, 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) The IO server is not really security critical as far as I understood. Is this correct? 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? Thanks in advance, 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 00:14 To: l4-hackers@os.inf.tu-dresden.de Subject: Re: Checking executables before running them in L4re/fiasco On Sat Aug 30, 2014 at 14:02:41 +, Masti Ramya Jayaram wrote: > I am using fiasco/l4re to run applications (say hello world) and > L4linux. The module list in the two cases looks like this: > > entry hello-cfg > kernel fiasco -serial_esc -freq=533000 > roottask moe rom/hello.cfg > module l4re > module ned > module hello.cfg > module hello > > entry l4linux > kernel fiasco -serial_esc -freq=533000 > roottask moe rom/l4linux.cfg > module l4re > module ned > module l4linux.cfg > module io > module vmlinuz > module ramdisk-x86.rd > > I would like to add some functionality that performs a few checks on > hello and vmlinuz before they are executed. In this context, I have > the following questions: > > a. Where is it best to implement such functionality - moe or ned? Or > should I implement a separate server and do this? You can just write your own program for that. In this program, just do normal open()/read()/mmap() on path "rom/hello" / "rom/vmlinuz". > b. I need access to an special range of IO memory when I perform the > checks. i guess I could always use the io module and do > "l4io_request_iomem()" . Would that be the right way to do it from > moe/ned? Yes, just do l4io_request_iomem() to get the IOMEM, however, not from moe nor ned. Ned is just starting io, so you do not have access to io easily from within ned. No problem in a separate program. > c. Is there a way to allocate/reserve a dedicated range of physical > memory to these applications (hello/vmlinuz) so that they get > allocated the same chunk everytime (of physical memory)? You mean for the images? They are placed in memory by the bootloader (and/or bootstrap), so they'll have the same memory location everytime given the bootloader is doing it the same way everytime. They're not moved around afterwards. 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
Re: Checking executables before running them in L4re/fiasco
On Sat Aug 30, 2014 at 14:02:41 +, Masti Ramya Jayaram wrote: > I am using fiasco/l4re to run applications (say hello world) and > L4linux. The module list in the two cases looks like this: > > entry hello-cfg > kernel fiasco -serial_esc -freq=533000 > roottask moe rom/hello.cfg > module l4re > module ned > module hello.cfg > module hello > > entry l4linux > kernel fiasco -serial_esc -freq=533000 > roottask moe rom/l4linux.cfg > module l4re > module ned > module l4linux.cfg > module io > module vmlinuz > module ramdisk-x86.rd > > I would like to add some functionality that performs a few checks on > hello and vmlinuz before they are executed. In this context, I have > the following questions: > > a. Where is it best to implement such functionality - moe or ned? Or > should I implement a separate server and do this? You can just write your own program for that. In this program, just do normal open()/read()/mmap() on path "rom/hello" / "rom/vmlinuz". > b. I need access to an special range of IO memory when I perform the > checks. i guess I could always use the io module and do > "l4io_request_iomem()" . Would that be the right way to do it from > moe/ned? Yes, just do l4io_request_iomem() to get the IOMEM, however, not from moe nor ned. Ned is just starting io, so you do not have access to io easily from within ned. No problem in a separate program. > c. Is there a way to allocate/reserve a dedicated range of physical > memory to these applications (hello/vmlinuz) so that they get > allocated the same chunk everytime (of physical memory)? You mean for the images? They are placed in memory by the bootloader (and/or bootstrap), so they'll have the same memory location everytime given the bootloader is doing it the same way everytime. They're not moved around afterwards. 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
Checking executables before running them in L4re/fiasco
Dear all, I am using fiasco/l4re to run applications (say hello world) and L4linux. The module list in the two cases looks like this: entry hello-cfg kernel fiasco -serial_esc -freq=533000 roottask moe rom/hello.cfg module l4re module ned module hello.cfg module hello entry l4linux kernel fiasco -serial_esc -freq=533000 roottask moe rom/l4linux.cfg module l4re module ned module l4linux.cfg module io module vmlinuz module ramdisk-x86.rd I would like to add some functionality that performs a few checks on hello and vmlinuz before they are executed. In this context, I have the following questions: a. Where is it best to implement such functionality - moe or ned? Or should I implement a separate server and do this? b. I need access to an special range of IO memory when I perform the checks. i guess I could always use the io module and do "l4io_request_iomem()" . Would that be the right way to do it from moe/ned? c. Is there a way to allocate/reserve a dedicated range of physical memory to these applications (hello/vmlinuz) so that they get allocated the same chunk everytime (of physical memory)? Thanks in advance, ramya ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
