August 2006 - l4-hackers - example.com Site

Re: current_thread_info
by Oskar Senft 12 Aug '06

12 Aug '06

Hi! >>> You need to call l4x_prepare_irq_thread(current_thread_info()) in your >>> thread before doing anything serious in there. >> Ok, sounds good. Unfortunately I cannot find it in my snapshot (May >> 5th, 2006) - since when should it have been in? > > l4x_setup_ti_thread_stack_irq(current_thread_info()) Great, thank you! That solved my problem. Could you please add the necessary line EXPORT_SYMBOL(l4x_setup_ti_thread_stack_irq); in arch/l4/kernel/main.c ? Best regards Oskar. -- Sirrix AG security technologies - http://www.sirrix.com Oskar Senft eMail: o.senft(a)sirrix.com Tel +49 (681) 936 251 - 119 Fax +49 (681) 936 251 - 519 get public key from keyserver Fingerprint 6FC6 3E44 233F 7F4B 33C7 A8D0 2EDA F3BA B5A3 0BA4 This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.

2 1

The "region overlap" problem in the L4/Fiasco hello example
by chenggh 12 Aug '06

12 Aug '06

Hi,everyone: When I boot the hello example in the L4/Fiasco. there is a "region overlap" in the booting information. I don't why it could be like this. The grub configuration and the error information is following: Grub: title fiasco_hello_new kernel (hd0,1)/boot/fiasco_hello_new/bootstrap -comport 1 -serial module (hd0,1)/boot/fiasco_hello_new/main -nokdb module (hd0,1)/boot/fiasco_hello_new/sigma0 module (hd0,1)/boot/fiasco_hello_new/roottask module (hd0,1)/boot/fiasco_hello_new/hello minicom_log: L4 Bootstrapper Loading (hd0,1)/boot/fiasco_hello_new/main Kernel at 00002000-0038f408 Detected new-style DD-L4(v2)/Fiasco x86 Loading (hd0,1)/boot/fiasco_hello_new/sigma0 Loading (hd0,1)/boot/fiasco_hello_new/roottask loaded module section: [0028d000-00324e13) .Roottask syms/lines (copy) overlaps with: [00300000-0038f408) (hd0,1)/boot/fiasco_hello_new/main [00002000-0005ae70) (hd0,1)/boot/fiasco_hello_new/main [0005b000-0005fcfd) (hd0,1)/boot/fiasco_hello_new/main [00090000-0009432d) (hd0,1)/boot/fiasco_hello_new/sigma0 [00095340-00096824) (hd0,1)/boot/fiasco_hello_new/sigma0 [0009f000-00100000) BIOS area [00100000-0010dc04) bootstrap [0013f000-0028ccb0) Modules Memory [00300000-0038f408) (hd0,1)/boot/fiasco_hello_new/main [1dff0000-ffffffff) Deep Space region overlap Thanks! Cheng

4 3

current_thread_info
by Oskar Senft 11 Aug '06

11 Aug '06

Hi L4Linux experts! Is it right, that the function current_thread_info (and dependent functions like "current") should not be called from threads which are created by "l4lx_thread_create"? I always get pagefaults while trying this ... *l4lx | L4RM: [PF] read at 0x99999c50, ip 004f9afe, src E.16 Is there a possibility to enable this function? Regards Oskar. -- Sirrix AG security technologies - http://www.sirrix.com Oskar Senft eMail: o.senft(a)sirrix.com Tel +49 (681) 936 251 - 119 Fax +49 (681) 936 251 - 519 get public key from keyserver Fingerprint 6FC6 3E44 233F 7F4B 33C7 A8D0 2EDA F3BA B5A3 0BA4 This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.

2 1

Re: L4Linux + Fiasco-ux
by Daniel Vandersee 10 Aug '06

10 Aug '06

Adam Lackorzynski wrote: > On Wed Aug 09, 2006 at 17:47:16 +0200, Daniel Vandersee wrote: > >>Adam Lackorzynski wrote: >> >>>Please enable "Use ldso for loading" in the L4Linux configuration. >>>Should also be default by tomorrow. >>> >> >>Thank you, but now the loader complains about a missing libld-l4.s.so >>which I can't find anywhere. > > > libld-l4.s.so is built in the ldso package. > I dowloaded the ldso package and recompiled l4linux (with ldso) as well as l4env, but I'm afraid this was wasn't the problem - I still get the same error. > loader | vmlinuz26.ux: Starting application using libld-l4.s.so > loader | vmlinuz26.ux,#f: Loading binary > fuxfprov| open "/home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2/libld-l4 > fuxfprov: .s.so" by D.02 > loader | vmlinuz26.ux,#f: Loading ldso > loader | vmlinuz26.ux,#f: Starting libld-l4.s.so at 00013e40 via 0000bba8 > fuxfprov| open "./libloader.s.so" by F.00 > fuxfprov| Can't open "./libloader.s.so": -2 > fuxfprov| open "/home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2/./libloa > fuxfprov: der.s.so" by F.00 > fuxfprov| open "vmlinuz26.ux" by F.00 > fuxfprov| Can't open "vmlinuz26.ux": -2 > fuxfprov| open "/home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2/vmlinuz2 > fuxfprov: 6.ux" by F.00 > l4lx | ======> L4Linux 2.6 starting... <======== > l4lx | Linux version 2.6.17-l4 (user@kubuntu) (gcc-Version 3.3.6 (Ubuntu 1: > l4lx : 3.3.6-8ubuntu1)) #4 Wed Aug 9 18:41:29 CEST 2006 > l4lx | Binary name: vmlinuz26.ux > l4lx | Kernel command line (9 args): mem=64M load_ramdisk=1 ramdisk_size=163 > l4lx : 84 root=1:0 l4env_rd=/home/user/ext/l4env_060809/DROPS/bin/x86_58 > l4lx : 6/l4v2/rd1 panicblink=0 lang=de video=l4fb:640x400@16,xpos:10,ypos:10 > l4lx : ,refreshsleep:150,title:DamnSmallLinux noirq > l4lx | Image: 00400000 - 0068f000 [2620 KiB]. > l4lx | Areas: Text: 00400000 - 005c6000 [1816kB] (a bit longer) > l4lx | Data: 005c6000 - 006025ac [241kB] > l4lx | Initdata: 00606000 - 00626000 [128kB] > l4lx | BSS: 00626000 - 0068d1c0 [412kB] > l4lx | l4lx_thread_create: Created thread 0f.03 (tamer) > l4lx | Using tamed mode. > l4lx | l4lx_thread_create: Created thread 0f.04 (server) > l4lx | main thread will be 0f.04 > l4lx | l4env_register_pointer_section: addr = 00604000 size = 569344 > l4lx | sec-w-init: virt: 0x00604000 to 0x0068efff [556 KiB] > l4lx | Noncontiguous region for sec-w-init > l4lx | sec-w-init: Number of physical regions: 2, 569344 Bytes > l4lx | sec-w-init: 1: Phys: 0x0141c000 to 0x0148d000, Size: 462848 > l4lx | sec-w-init: 2: Phys: 0x00ae6000 to 0x00b00000, Size: 106496 > l4lx | l4env_linux_startup thread 4. > l4lx | main thread: received startup message. > l4lx | Main thread running, waiting... > l4lx | setup_l4env_memory: Forcing superpages for main memory > l4lx | Main memory size: 64MB > l4lx | Main memory: virt: 0x00800000 to 0x047fffff [65536 KiB] > l4lx | Main memory: Number of physical regions: 1, 67108864 Bytes > l4lx | Main memory: 1: Phys: 0x0a400000 to 0x0e400000, Size: 67108864 > l4lx | Filling lower ptabs... > l4lx | Done (1260 entries). > l4lx | l4env_rd_path: /home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2 > l4lx : /rd1 > l4lx | Loading: /home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2/rd1 > fuxfprov| open "/home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2/rd1" by > fuxfprov: F.04 > l4lx | INITRD: Size of RAMdisk is 16384KiB > l4lx | RAMdisk from 04800000 to 05800000 [16384KiB] > l4lx | l4lx_thread_create: Created thread 0f.05 (timer.i0) > DMphys | ds 81, client F.00, rights 0x0003, has 0x0001 > DMphys | [7.0] dm_phys/server/src/map.c:620:if_l4dm_generic_fault_component(): > DMphys | DMphys: bad permissions > l4lx | L4RM: dataspace at 0x00400000-0x005c5fff, id 81 at 7.00 > l4lx | L4RM: dataspace manager call failed ("permission denied") > l4lx | L4RM: [PF] write at 0x00402860, ip 0040b2bc, src F.02 > l4lx | [F.0] l4rm/lib/src/pagefault.c:78:__unknown_pf(): > l4lx | unhandled page fault > > --PANIC, 'g' for exit-------------------------------ESP:00629d20 EIP:a00bdcd3 > (f.00) jdb: ^ Kind regards, Daniel

3 3

L4Linux output on serial line?
by Andreas Niederl 09 Aug '06

09 Aug '06

Hi, I would like to have the output from the L4Linux kernel on the serial line for debugging purposes because Qemu doesn't allow me to scroll back in its output window. Could somebody give me hints on how to doing that? I already configured Grub for having serial support from bootstrap and Fiasco. Regards, Andi

1 1

exec doesn't respect all_sects_writable
by Andreas Niederl 09 Aug '06

09 Aug '06

Hi, I wanted to run a current L4Linux using the CVS version of DROPS and got a page fault when the Linux code is self-modified. I was told to use the option all_sects_writable for the loader, but this apparently does not work when not using ldso. Exec seems to ignore this option and maps in the L4Linux space read only. This looks like a bug to me. Regards, Andi

2 2

L4Linux + Fiasco-ux
by Daniel Vandersee 09 Aug '06

09 Aug '06

Hello, when I try to run L4Linux (compiled for ux) on top of Fiasco-ux I get the following error: $./lx con ... > fuxfprov| open "/home/user/ext/l4env_060809/DROPS/bin/x86_586/l4v2/rd1" by > fuxfprov: F.04 > l4lx | INITRD: Size of RAMdisk is 16384KiB > l4lx | RAMdisk from 04800000 to 05800000 [16384KiB] > l4lx | l4lx_thread_create: Created thread 0f.05 (timer.i0) > DMphys | ds 67, client F.00, rights 0x0003, has 0x0001 > DMphys | [7.0] dm_phys/server/src/map.c:620:if_l4dm_generic_fault_component(): > DMphys | DMphys: bad permissions > l4lx | L4RM: dataspace at 0x00400000-0x005c5fff, id 67 at 7.00 > l4lx | L4RM: dataspace manager call failed ("permission denied") > l4lx | L4RM: [PF] write at 0x004026d0, ip 0040b2bc, src F.02 > l4lx | [F.0] l4rm/lib/src/pagefault.c:78:__unknown_pf(): > l4lx | unhandled page fault > > --PANIC, 'g' for exit-------------------------------ESP:0000893c EIP:000223b3 > (f.00) jdb: I tried several L4Linux configurations without success. Any help would be appreciated. Kind regards, Daniel

2 1

L4 Semaphore in L4Linux
by Oskar Senft 09 Aug '06

09 Aug '06

Hi! Is it possible to use the L4 Semaphore and Lock within a L4Linux kernel module somehow? I believe, that both is already used within the L4Linux kernel itself, but the symbols are not exported to other kernel module. When I now try to use them, the linker tells that the following symbols are undefined: "l4semaphore_restart_down" "l4semaphore_restart_up" "l4thread_myself" "l4semaphore_thread_l4_id" If I try to add the libsemaphore.a, the situation gets worse and the following symbols are undefined. "LOG_flush" "_exit" "l4thread_create_long" l4thread_get_prio" "l4sigma0_kip_kernel_has_feature" "l4thread_l4_id" "l4thread_myself" "l4thread_data_set" "l4thread_data_get" "LOG_logL" "l4thread_set_prio" "l4thread_data_allocate_key" Even adding more libs to the L4Linux kernel module does not resolve all symbols - I'm not even sure if that could work at all. These are the libs already linked in (and making the kernel module work - without semaphores / locks): libdm_generic.a \ libl4env.a \ libl4env_err.a \ libgeneric_blk-server.a \ libl4sys.a \ libnames.a \ libroot.o.a \ libdiet_c.a \ I also tried to simply load the kernel module with unresolved symbols - in hope that the running kernel would solve it - to no success. Does anyone have a solution to this? Best regards Oskar. -- Sirrix AG security technologies - http://www.sirrix.com Oskar Senft eMail: o.senft(a)sirrix.com Tel +49 (681) 936 251 - 119 Fax +49 (681) 936 251 - 500 get public key from keyserver Fingerprint 6FC6 3E44 233F 7F4B 33C7 A8D0 2EDA F3BA B5A3 0BA4 This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.

2 4

Semaphore library error on L4Env/Fiasco-UX
by Andreas Niederl 08 Aug '06

08 Aug '06

Hi, using the current CVS version of Fiasco and L4Env I get the following error on startup of the system with Fiasco-UX: exec | Startup: semaphore lib initialization failed (-1)! The task on which it fails varies depending on which startup script from l4/tool/runux is executed but it's always the first or second task that starts. L4Env is compiled with gcc-3.3.6 and Fiasco with gcc-4.0.2. Is this a known problem? Regards, Andi

2 3

Re: HURDNG : Which type of OS design could we have to think nowadays ?
by Ernst Rohlicek jun. 08 Aug '06

08 Aug '06

Hello Guillaume, Hello list, This is a long post and I hope to have made it somewhat interesting as well. Please stay with me :-) > Here is the start point of my reflexion : > > http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00053.html In this post, Mr. Shapiro compares roads of action for a next-generation Hurd and starts out with: "This will sound strange coming from me, but it may turn out that HurdNG should build it's own microkernel. I do not think this is a good idea, but let me try to enumerate the alternatives and articulate the advantages and disadvantages as I see them." His conclusions are true: Using something existing is great, PROVIDED it fits reasonably well - and it must fit almost the way it came. You may be able to retro-fit a few bits here and there, but that's it. It is also my experience that if you try to change a program in fundamental ways, it's easier to redo it rather than trying to re-orient it. Think of changing a KDE application into a GNOME application ... and the closer you get toward the kernel, the more work you have with re-orienting it. You have translated your design into code (created an "instance" so to speak) and we all know that C code is not friends with large re-writes. Another thing is that FAR too many people shy away from starting out anew. We're not a commercial company with time pressure. We have learned from the last "iteration", know a lot of the issues and mistakes - plus, we have time. Instead of patching and re-orienting and hoping, we should enter the next iteration and put to use what we've learned. Another snippet from the above message: "If, after you look at the alternatives, you still think that building or modifying a micro-kernel sounds good, try to assemble a team. If you can't, stop and look for another way. In my opinion, the L4-Hurd and mainstream Hurd communities simply do not have the (human) resources to build both a microkernel and an OS before most of this list has died of old age." Yup, there's action required... if not, well ... read again about that age thing. Just wanted to point that out... > I believe that we can do extremely complex and reliable software with > a few people, thanks to the powerful formal and design tools available > now. > > Time is maybe our worst ennemy : more and more technologies are > created day by day and we need to understand and to be able to use > them And it's maybe our better friend : as the hardware/software > becomes more and more complex, the tools to develop them becomes more > powerful too. > > The tools developed to understand and create complex systems give us > the ability to design and implement an OS design secure & reliable. You mention some interesting methods and utilities. I've used formal design myself (IBM's Rational - great tool) and it really takes away a lot of burden. You can change some relationships in the design view and they get translated / "instantiated" right into code. Usually you have to just fill in the blanks and application logic. I wonder if the things you mentioned can be used not just for modeling specific types of applications and relationships, but for more generic (Hurd servers, maybe even kernel?) programs. Could you find out about that? Rationale: In projects you often just HAVE to re-adapt the design of your program after iteration 1 ... and any way of quickly re-adapting the code to fit the new design is just GOLD. That's in my opinion why there is things like re-factoring, meta-programming, formal and model-based design and lots of scripting (prototyping?) languages. Would you implement a proof-of-concept or prototype rather in Python or in ANSI C ? With manual memory allocation, char arrays, buffers, pointers, Makefiles, autotools stuff...? Guillaume, your idea is quite on the spot, I believe. I personally acknowledge that you can do great prototypes with formal design and high-level languages. Look over to the development of the seL4 / L4.sec kernel: http://ertos.nicta.com.au/research/sel4/tech.pml They themselves use a machine simulator, which catches all kernel requests and hands them to the "kernel", which is developed outside of the simulator in the Haskell programming language. I'm convinced that they're able to go through design and verification iterations so much faster. And besides, their specification = implementation looks almost the same as a model description from model-based engineering. I guess that later, when the algorithms have been optimized and they found that they've developed a useful design for their requirements, they might actually implement it in C (though comparison shows that the Haskell GHC compiler also produces very fast code), search for "performance" or "slow" here: http://www.haskell.org/haskellwiki/Introduction But that Haskell thing just as a side note. It's important to point out that fast prototyping, fast design verification (and -adaption until we know, "This is it, we have it"), fast creation of code instances from a model or directly use a high-level language for initial design creation is almost a key point. > -The first one is the start of any important project : developers can > have the possibility to share complex ideas with minimum requirements > and to integrate them in a coherent environment. ( see > http://www.gnu.org/software/hurd/ => 23 years old and even the goals > are not well defined ) That's an under-estimated point ... and yet a vital one. > -The second feature provide any user the ability to develop on it with > existing materials and to have the support of developers of legacy OS. Yes, transition is important. Going too far out with GNU Hurd means no good. > -The third one needs that a device driver framework needs to be > rapidly envisaged. ( again http://www.gnu.org/software/hurd/ => no > good driver kit at this date, the same for linux : > http://www.kroah.com/log/2006/05/24/, 15 years later ). Who wants to > have an OS that boots only a black screen with a beep sound ? If we > follow the Moore law, an OS design of the future would be thought for > quadruple play ( mobility, audio, video, Internet ) and security of > course. Yes, being able to fulfill use-cases is important. Besides, any developer for a possibly next-gen OS wants to listen to some MP3s :-) > Abstraction will be the solution, Putting more and more layers of abstraction between the hardware and the program logic usually is no good. What exactly do you mean with abstraction? Or: What kind of abstraction do you mean? > I believe that HurdNG had to focus one 2 things ( lol :-), easy to tell, > hard to design ) : security and performance. Security because all > devices are becoming more and more connected and performance because of > the Moore's law. Security indeed is becoming more and more important; as as maintainability and modularity. > *First option : > > Should we support 386 and let the OS die with this obselete hardware or > think to the future and enjoy the power of 64 bits and multicore that > are becoming standards ? > > The ideas have to go more far that the present, if the HURDNG ( forget > now UNIX:-) ) want to be a good option/successor to Linux. > > A Single Adress Space OS ( 64 bits = 256 Tb, we have time before > exploiting all this power => it would be moore easy to get rid of ACL > because of easier implementation of persistence) and a language/main > library thought for massive multithread (CSP or Concurrent/Parallel > Haskell => get rid of C/ maybe GNU/UNIX/POSIX too :-) ) . > > http://www.torsion.org/ > > http://www.cs.dartmouth.edu/~dfk/papers/kotz:addrtrace.pdf > > http://www.wotug.org/ > > http://www.eros-os.org/pipermail/e-lang/1999-November/003069.html > > http://tunes.org/wiki/Orthogonal_Persistence Persistence: Well, I'm not sure whether orthogonal persistence (in my interpretation this is quite similar to hiberation / suspend to disk) is really required - better: what it's benefits in a general-purpose OS for non-embedded CPUs are... After all you can still store your caps on disk, if you would like to. Design for old HW or for the future: I would not design a new OS for a machine you can't buy in stores anymore since 5 years (in 2001 we had Athlons and Pentium 3 / 4). Rationale: If you say that a new OS will have a lifetime of 10 years, then you will think back and say, "Why the hell did they let themselves get restricted by CPUs, which were several generations behind - already back then?!" Looking from today's perspective: If you design a little bit "too big" or "far ahead" for today's measures (64-bits where possible, massively threaded and laid out for SMP, among many other decisions), then today's design might still be ... hm, well at least MAKE SENSE in 10 years. > *Second option : > > Explore new ideas, maybe too innovative (Have to carefully choose/adapt > the language). > > http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00053.html > > I would add a fourth option : Get rid of a kernel : Well, you need need some kind of authority. "Processes can all be equal, but some have to be more equal." And the Exokernel idea is probably great for very specialized purposes, so remember that GNU/Hurd is supposed to be a general-use OS. If I misunderstood, we can further discuss of course. > http://www.tunes.org "Reflective OS" sounds tempting, though I personally think this belongs more into AI - intelligent, integrated assistants and the like. Of course it's okay that you mention it - I guess we all honor your right to bring new things to the table :-) > "Isaac is an operating system purely made by dynamicaly interconnected > prototype object. Each macro-object run on top of the processor. > > IsaacOS is not an interface with a standard kernel. IsaacOS is fully > made with only object. No file, no process, no kernel, just and only > object." > > http://isaacos.loria.fr/index.html I have yet to read up on "prototype-based" languages and this specific language here - hm, "based on Smalltalk", "uses GCC", "fast code like C", "used for writing operating systems", " Generally, I believe that we don't have to use C anymore to write hardware-near programs - back then in the 70s, 80s and even still in the 90s it was fine, but not today. There are fast alternatives with better facilities. BTW, think back to the 70's when C was invented. Back then it must have been like, "Oh my god, this is high-tech - are you sure you want to use that new, crazy 'C' language for your OS?" ... why are we so shy to use something newer and safer than C? (Safer as in eg. type safety) There are alternatives are in place. As motivation, here is a link to a WORKING implementation of Unix in C++, which is even binary compatible with Linux: http://www.unixlite.org/index.html So it is possible. As mentioned in my reply-paragraphs above, I suggest one of the following for a new kernel for GNU/Hurd - should seL4 / L4.sec and Coyotos be too far off the goals and requirements ... wait, WHAT goals and requirements BTW? - But I digress. ;-) Anyway, in that case, I would suggest using one or more or a mix of the following roads: 1. Using an intermediate prototyping language and/or some (needs TBD) model-based approach 2. Using an intermediate high(er)-level language for prototyping and starting implementation in C once we're sure about a (for our purposes) complete and sound design 3. Writing in a high(er)-level language which can be compiled into fast code (as fast like C), but which does not allow you to shoot yourself in the foot (too often) and which allows for relatively easy re-orientation of the code. For any of that to work, we need to know (and then get clearer) about things like: Goals, ideas, what Hurd really could do better than others ... how your computer(s) would work differently if it would be running your ideal version of Hurd, according to your ideas...? What are your ideas BTW? > Best Regards, > > Guillaume FORTAINE > Likewise, thanks for the input. --Ernst Rohlicek jun.

1 0