- l4-hackers - example.com Site

L4Re Hello World Qemu vs Hardware
by André Bispo 17 Mar '15

17 Mar '15

Hello guys,I was trying to run Fiasco and L4 and i successfully created the ISO image and ran it on QEMU.How can i run it on my pc hardware? Can you guys provide me some steps on how to do it? Thank you in advance,André Bispo.

2 1

Checkpoint/Restore on L4Re
by Stark, Josef 16 Mar '15

16 Mar '15

Hello, I am interested in Checkpoint/Restore-functionality on L4Re. I found the paper "Stay Strong, Stay Safe – Enhancing Reliability of a Secure Operating System" (http://os.inf.tu-dresden.de/papers_ps/vogtdoebel-IIDS2010.pdf) where it is written that such a mechanism was already developed for L4Re. However, I couldn't find such a thing inside the L4Re snapshot. Could someone tell me what the current state of this is, and where to find it (if it's publicly available)? Sincerely, Josef

2 1

Running a task without region manager
by Stark, Josef 16 Mar '15

16 Mar '15

Hey, I am wondering what would happen (i.e. which disadvantages I get) if I tried to run a task directly, without l4re_kernel. More precisely: Ned, file lua_exec.cc, line 408: '_l.launch(&am, "rom/l4re", ldr);': What would happen, if the second argument ("rom/l4re") was replaced by a variable holding the actual binary name that should be started (e.g. "rom/hello"), which thus would be started without l4re? Best regards, Josef

2 2

Disable log color
by teclis High Elf 15 Mar '15

15 Mar '15

Is there a way to disable the log color so that the logger doesn't insert control codes for color into the output stream.

4 4

Networking issues (ankh/lwip/drivers/?)
by Stark, Josef 13 Mar '15

13 Mar '15

Hi all, while experimenting with network apps in L4Re, I experienced some issues: 1. (not important) DHCP isn't working: The lwip example (ankh/examples/lwip) doesn't seem to work, neither with the integrated DHCP-Server of QEMU, nor with a dnsmasq running on a tap interface plugged into a vde_switch. Workaround: Replacing "dhcp_start(&my_netif);" with "netif_set_default(&my_netif); netif_set_up(&my_netif);" and, beforehand, setting the adress manually with "IP4_ADDR()" (#include <ipv4/lwip/ip4_addr.h>). I also couldn't get DNS to work. 2. (not so important) some NIC-drivers aren't working: QEMU-x86 can emulate the following interfaces: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. According to its Makefile, ankh supports the following interfaces: NE2K, LOOP, RTL8139, RTL8169, PCNET, E100, E1000, E1000E and UX. However, of the intersection (ne2k_pci, rtl8139, pcnet und e1000) only ne2k_pci seems to work somewhat reliably. The others simply don't work with or without some errors being shown by ankh. With ne2k_pci I can only get a throughput of about 1MB/s, I'm guessing because the card is pretty old. 3. Sporadic delays/ errors: Although this didn't happen too often, sometimes, when a client tried to send some small data to a server in another QEMU-instance, I experienced delays in the range of about 1 second before the receiver got the data. On other occassions, a connection could not be established at all. However, no error messages were shown. 4. Multithreaded server issues: I couldn't manage to get a multithreaded server to work. Neither a server, a) which receives data on two different ports, each handled in a separate thread, nor b) which receives data on a single port, handles however multiple clients simultaneously via separate threads, did work. Since a) and b) seem somewhat related I will elaborate only on b): As long as just one client is connected to the server, sending and receiving on both ends works fine. As soon as a second client (in another QEMU-instance, all connected via a vde_switch) tries to send data after connecting, both connections from server to the first and second client break down and no data gets through anymore. No errors shown. Finally the write() calls timeout. Just as I wrote this, it did one time actually work, both clients connected, able to send and receive data. But I couldn't reproduce this success. After removing the L4Re-specific parts of the code I compiled and ran it on Linux, where it does work flawlessly, even with 6 simultaneous client processes, not just 2. I'm not sure why these issues occur, either there are bugs somewhere in L4Re's network stack or the NIC drivers, but it's also perfectly possible that I made some mistakes or that vde_switch doesn't work correctly (Although I did test whichever was possible (e.g. 4.a ) also only using simple QEMU TCP sockets). In order to be able to reproduce the results, I attached my configuration (see below and attachments). Hopefully, someone can tell me what's going on here. I would really be glad. Thank you! Josef ---------------------------------------- Configuration: First of all, I run "sudo vde_switch -daemon -mod 660 -group users". This is only neccessary once; the vde_switch is then used by all QEMU-instances. To start the scenario, I use a simple script (see attachment run.sh), which starts all the QEMU-instances and sets different MAC-adresses for each instance (in cooperation with Makeconf.boot). server.c and client.c are heavily based on the lwip example. While server_linux.c and client_linux.c are the stripped-down files I used for testing the network code on linux, all the other attached files are needed for running the L4Re-scenario.

1 0

dde kit
by Daniel Krefft 13 Mar '15

13 Mar '15

Hi there, we want to use the ddekit in one of our courses next summer term. So, to get comfortable with the setup and the toolchain I would like to ask if a step by step guide to get the ddekit up and running exists? Best regards, Daniel -- ***************************************************************** * Daniel Krefft M.Sc. * * T: +49-89-289-18791 * * * Technische Universitaet Muenchen * Fakultaet fuer Informatik - F13 (Prof. Baumgarten) * Boltzmannstr. 3 * D-85748 Garching bei Muenchen * Germany *****************************************************************

2 3

Re: Porting Fiasco.OC to RISC-V - Questions
by Hesham ALMatary 12 Mar '15

12 Mar '15

Hi Adam, Thanks for your reply. I thought it would be a good idea to start with L4Re to familiarize myself with Fiasco.OC/L4Re structure, and chose to start with L4Re because it doesn't need a lot of architecture dependent code. So, after your reply, I'd work on getting bootstrap working and loading the "to-be-evolved" Fiasco.OC RISC-V kernel. This would allow me to debug and test Fiasco.OC/risc-v as I add new code/features their. Best, Hesham On Thu, Mar 12, 2015 at 12:48 PM, Hesham ALMatary <heshamelmatary(a)gmail.com> wrote: > Hi Adam, > > Thanks for your reply. I thought it would be a good idea to start with > L4Re to familiarize myself with Fiasco.OC/L4Re structure, and chose to > start with L4Re because it doesn't need a lot of architecture > dependent code. So, after your reply, I'd work on getting bootstrap > working and loading the "to-be-evolved" Fiasco.OC RISC-V kernel. This > would allow me to debug and test Fiasco.OC/risc-v as I add new > code/features their. > > Best, > Hesham > > On Wed, Mar 11, 2015 at 11:14 PM, Adam Lackorzynski > <adam(a)os.inf.tu-dresden.de> wrote: >> Hi, >> >> On Wed Mar 11, 2015 at 17:53:58 +0000, Hesham ALMatary wrote: >>> I'm considering porting Fiasco.OC/L4Re to RISC-V architecture (for >>> both my research and GSoC). So, I started reading the documentation >>> and building the environment (For Fiasco.OC and RISC-V tools), and >>> QEMU (the emulator that I'll use initially) is running Hello World >>> example just fine. >>> >>> After some reading, I wanted to start adding support for building L4Re >>> for RISC-V (is this a good start?), and I came up with some questions. >>> >>> There are two variants of RISC-V ABI (32 and 64 bit) should I provide >>> both or just 64-bit version? >> >> For starting, just choose one. The other type could be done later. >> >>> What are the minimal packages and/or Fiasco.OC system components that >>> need to be implemented to get Hello World working? Please correct me >>> if the following L4Re list is not right (contains more than needed, or >>> lack others): >>> >>> "bootstrap, sigma0, moe, Log, libc, libc_minimal, cxx_util, cxx_io, >>> cxx_base, cxx_io_kdebug,l4sys-direct, l4sys" >> >> Good list. To find out the exact list you can just do >> "make O=... sigma0 moe bootstrap l4re_kernel hello" and then see in the >> build directory what was actually built. >> >> But actually for starting, you just need boostrap because then comes the >> kernel that needs to work before anything more needs to be done for the >> user level components. >> >>> Some of the packages are architecture dependent which need some code >>> from other projects (like uclibc), should I add them all? FYI, newlib >>> has support for riscv, but uclibc doesn't, >> >> True that uclibc does not support riscv natively. But there's nearly no >> architecture dependent code needed, so this is not really an issue. >> >>> how can I make the build >>> system choose specific packages for the target architecture (riscv in >>> this case) and maybe neglect building others? >> >> One way is putting 'broken' files in to package's root directory (e.g. >> l4/pkg/hello/broken). Then there's the SYSTEMS variable which defines >> for which architecture a library/program can be compiled for. Its >> default is all architecture, so by not changing the default and just >> adding riscv-l4f where you want it could also be a way. >> >> >> >> Adam >> -- >> Adam adam(a)os.inf.tu-dresden.de >> Lackorzynski http://os.inf.tu-dresden.de/~adam/ >> >> _______________________________________________ >> l4-hackers mailing list >> l4-hackers(a)os.inf.tu-dresden.de >> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers > > > > -- > Hesham -- Hesham

2 1

Porting Fiasco.OC to RISC-V - Questions
by Hesham ALMatary 11 Mar '15

11 Mar '15

Hi all, I'm considering porting Fiasco.OC/L4Re to RISC-V architecture (for both my research and GSoC). So, I started reading the documentation and building the environment (For Fiasco.OC and RISC-V tools), and QEMU (the emulator that I'll use initially) is running Hello World example just fine. After some reading, I wanted to start adding support for building L4Re for RISC-V (is this a good start?), and I came up with some questions. There are two variants of RISC-V ABI (32 and 64 bit) should I provide both or just 64-bit version? What are the minimal packages and/or Fiasco.OC system components that need to be implemented to get Hello World working? Please correct me if the following L4Re list is not right (contains more than needed, or lack others): "bootstrap, sigma0, moe, Log, libc, libc_minimal, cxx_util, cxx_io, cxx_base, cxx_io_kdebug,l4sys-direct, l4sys" Some of the packages are architecture dependent which need some code from other projects (like uclibc), should I add them all? FYI, newlib has support for riscv, but uclibc doesn't, how can I make the build system choose specific packages for the target architecture (riscv in this case) and maybe neglect building others? Any other feedback or comments are welcomed. -- Hesham

2 1

shared dataspace for l4re_kernel/ registering additional caps in ned
by Stark, Josef 11 Mar '15

11 Mar '15

Hello all, for a project, I want to be able to load (elf-)binaries not only from the filesystem, but also from the network (receive binary, then start it.) For this, I will write a L4 app (let's call it "manager" for now) which handles the network part and then tells ned to start the received binary via a special "filename". I already modified ned so that its LUA-interface is exposed to other apps via a capability. But here comes the first problem: Normally you specify the capability table of a task and an IPC channel in the lua-config file, which ned reads. Ned then prepares the channel and the caps table and starts the task, which then can register the capability. Otherwise, registering fails (the example would do a printf("Could not register my service, is there a 'calc_server' in the caps table?\n");) So... how do I specify which capabilities ned itself can have/register? Currently, I need to have a lua-config which tells ned to start another instance of ned with the required permission to register the capability. But is there any way to avoid having two ned instances and making the first (and only) instance able to register the cap? Second problem: I found out, that ned (also moe) doesn't start the desired app directly but instead starts the l4re binary (source located in src/l4/pkg/l4re_kernel), passing it the filename of the desired binary. l4re, once started, gets the dataspace of this file and then ultimately starts the app. For my purpose, I would modify l4re_kernel so that if it detects the special "filename" mentioned above, it does not read the file from the filesystem but loads the binary that the "manager" received over the network. To get the data from the manager to the l4re_kernel instance, I thought that a shared dataspace or a shared memory area l4shmc_area_t like in prdocons.c example would be suitable. However, again, both of these things normally require special parameters in the lua config file (as can be seen in the examples), but I have no clue how to do this to l4re_kernel since it is not loaded from such a file, but loaded implicitly each time a new task is started. (so I guess this makes it even harder than the problem with ned since ned is only started once.) Does anyone have ideas on how to solve these? If someone finds that I phrased this too opaque, please let me know. Best regards, Josef Stark

3 16

add new package
by 水镜 11 Mar '15

11 Mar '15

hi ,i want to add a new package which is a lib. i use the log package as my base. now my package can be compiled. but when i want to use it in the moe, i got this errors: Library dependencies missing: libdbgobj in directory '/home/watermirror/source/src/l4re/pkg/moe/server/src'; aborting. /home/watermirror/source/src/l4re/mk/binary.inc:363: *** Cflags dependencies missing: libdbgobj in directory '/home/watermirror/source/src/l4re/pkg/moe/server/src'; aborting.. how to solve this problem?

2 1