l4-hackers

l4-hackers@os.inf.tu-dresden.de

2827 discussions

Re: Define Addr. Space of Task
by ba_f 08 Jul '17

08 Jul '17

Hello again, this topic is still open. So, how can I link a Task to a specific address space? > Hi Adam, > > >> Linking a program to a specific location is well possible. >> However, the extra memory region is not part of the normal RAM but an >> extra piece of memory? How is it accessed? And how big is it? >> >> Adam > > > Yes, the secure ram is separate from the ordinary DRAM. > But, access to it is address based via ARM AXI. > > My design has a trusted L4re-App. > And i want to link the trusted app alone to the secure ram. > I argue that ordinary DRAM is easy to read out for an attacker that has > local access to the platform. > The secure ram is less easy to read-out, so the trusted app would be > more secure. > > > > > Greets, > > ba_f Thank you, ba_f

2 1

L4Re IPC share memory that share file in one Linux filesystem and be visible to other Linuxes
by Joyce Peng(彭美僑) 07 Jul '17

07 Jul '17

Hi L4, I want to share a file in one Linux filesystem and be visible to other Linuxes that all run on top Fiasco.OC. It seems an IPC communication between L4re vm tasks. And access a file in Linux filesystem is a mechanism of kernel block device driver. But I only notice two char device drivers that use L4re library l4shmc in L4linux. It is l4ser_shm and l4shmnet. May you give some information about this work how to work. Thanks. Joyce.peng(彭美僑)

2 3

Unit testing guidelines or resource
by jrodriguez＠uns.edu.ar 05 Jul '17

05 Jul '17

Hi L4 team, I'm looking forward for information about existent or recommended methodology to perform systematic test on single fiasco component or L4Re service. From what I see, there is not other option than running on qemu or target host. What I would really like is to get sort of fiasco&L4Re mock to be able to run systematic unit test on user level app but on my PC (avoiding the emulator). Any recommendation on this regard? Thought about fiasco UX, but not sure if that feature is still maintained. And if I jump into the complex task of designing this mock, any recommendation about l4re service which is more "isolated" from microkernel to take it as initial use case for such development? Well that's all by now. Thanks in advance for any feedback Best Agustin

2 1

Problem with L4re and L4Linux on Qemu/VMware
by Daniel (Xiaolong) Wang 27 Jun '17

27 Jun '17

Hi all, I’m sorry to bother, again… But I keep getting problems hope you can give me some advice. I’m trying to test out L4re +L4Linux on X86 and ARM i.MX6. I downloaded the newest l4re-snapshot-2006082114. I built Fiasco with Intel Pentium Pro and Virtualization (did not change anything else). I built L4re with Pentium Pro type CPU (everything else are default settings). Then I built L4Linux with the L4re builddir. I turned off 64-bit kernel, CPU selected Pentium-Pro, turned off most of the settings as the warning instructed. These are the settings of L4Linux that I enabled: Processor type and features: * DMA memory allocation support * Processor feature human-readable name * Fast CPU feature tests * Support for extended X86 platform * Single-depth WCHAN output * High memory support is OFF * Enable bounce buffers * X86 architectural random number generator * Enable seccomp to safety compute untrusted bytecode * Enable the LDT Power Management and ACPI options: * Suspend to RAM and standby * device power management core functionality * CPU Frequency scaling is OFF Bus Options: * PCI support * PCI access mode is Direct I was able to compile all three parts and build both iso image (for vmware fusion on macOS) and qemu simulator. I first tested hello, hello-cfg, hello-shared, frame buffer-example-x86, all of those works as expected. However when I tried to build L4Linux-basic and L4Linux-mag-x86. Not of them works. for L4Linux-mag-x86 the system shows a diagram “system is booting” then hang forever. for L4Linux-basic the image boot but freeze soon. The screen shows: l4cdds: No name given, not starting brd: module loaded l4cdds: no name given, not starting moused: ps/2 mouse device common for all mice l4x: Faking dummy RTC rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos rtc_cmos: only 24-hr supported rtc_l4x: l4x-rtc: Could not find ‘rtc’ cap rtc_l4x: probe of rtc-l4x failed with error -2 NET: Registered protocol family 17 L4IRQ: set irq type of 64 to 1 RAMDISK: ext2 filesystem found at block 0 RAMDISK: Loading 3072KiB [1 disk] into ram disk… done. VFS: Mounted root (ext2 filesystem) on device 1:0. Freeing unused kernel memory 188K (00494000 - 004c3000) Write protecting the kernel text: 2684K Write protecting the kernel read-only data 768k rodata_test: test data was not read only Please press Enter to activate this console. clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2845e81c5f6, max-idle_ns: 440795276432 ns clocksource: Switched to clocksource tsc Initially I thought it might related RTC so I checked out all Real time clock in L4Linux, but it still the same. Any help would be appreciated. Thanks -Dan

3 8

IRQ objects
by David Werner 23 Jun '17

23 Jun '17

Hi L4-hackers, i am currently working on a checkpoint/restore component (for the Genode framework) which aims at the migration of processes/components. When I first start the target component of the checkpointer, its object looks like this: 000204 :0016e* Gate 0015f* Gate 00158* Gate 00152* Gate 000208 :00154* Gate 0017e* Gate 0017f* Gate 00179* Gate 00020c :00180* Gate 00188* Gate -- -- 000210 : -- -- 0018a* Gate 0018c* Gate 000214 :0018e* Gate 00196* Gate 00145* Gate 00144* IRQ 000218 :00198* Gate -- -- -- 00021c : -- 0019c* Gate -- -- At position 000217 is an IRQ object which is used for signaling. I would like to know if this IRQ object carries any information which I need to store in order to recreate a new IRQ object for the restarted component. If you are interested in more context you can take a look at: https://sourceforge.net/p/genode/mailman/message/35904942/ Kind Regards, David Werner

2 1

L4re and L4Linux Compatible issue
by Daniel (Xiaolong) Wang 21 Jun '17

21 Jun '17

Hi all, I’m trying to use L4re to run L4linux. I successfully built the fiasco kernel and l4re with the default setting from the newest l4re-snapshot. However when I try to build L4linux it shows it shows: “ld: skipping incompatible /home/daniel/Desktop/l4re-snapshot/src/l4/builddir/lib/x86_pentium4/l4f/libl4sys-direct.a when searching for -ll4sys-direct” "ld: skipping incompatible /home/daniel/Desktop/l4re-snapshot/src/l4/builddir/lib/x86_pentium4/l4f/libl4sys.a when searching for -ll4sys" "ld: cannot find -ll4sys” I assume it is the platform of L4re I built is not compatible with the L4Linux settings. I built L4re for x86_586 and x86_pentium4. My question is that is there a compatible X86 CPU platform the works for both L4re and L4Linux? Should I built AMD64 instead? Thanks -Dan

2 2

L4re with L4Linux
by Daniel (Xiaolong) Wang 20 Jun '17

20 Jun '17

Hi all, I’m new to L4re. I would like to use L4re as a microvisor and run L4linux VM. Is there any tutorial shows how to build the system like that? Thanks -Dan

1 0

Re: l4linux: l4x_setup_memory:Cant get main memory
by Leslie Zhai 09 Jun '17

09 Jun '17

Hi Adam, Thanks for your hint! > Hm, tried adding more memory to the VM? Perhaps other users might experienced the same issue: L4x: Main thread running, waiting... L4x: Memory size: 64MB L4x: Setting superpages for main memory l4x_setup_memory: Can't get main memory of 65536kiB! Please try to add more memory to the VM. MOE[mem_alloc]: quota: limit=-1 Byte, used=9646080 Byte MOE[mem_alloc]: global: avail=52121376 Byte MOE[mem_alloc]: free list (start address/size): MOE[mem_alloc]: 0x210e0 - 0x213ff (800 Byte) MOE[mem_alloc]: 0x273400 - 0x273fff (3 kB) MOE[mem_alloc]: 0x370000 - 0x3fffff (576 kB) MOE[mem_alloc]: 0xba6000 - 0x18aafff (13 MB) MOE[mem_alloc]: 0x541a000 - 0x7838fff (36 MB) Terminating L4Linux. so I simply added "Please try to add more memory to the VM." Index: arch/l4/kernel/main.c =================================================================== --- arch/l4/kernel/main.c (revision 54) +++ arch/l4/kernel/main.c (working copy) @@ -1384,7 +1384,8 @@ if (l4re_ma_alloc_align(mem_chunk_sz[i], l4x_ds_mainmem[i], f, virt_phys_alignment)) { - LOG_printf("%s: Can't get main memory of %ldkiB!\n", + LOG_printf("%s: Can't get main memory of %ldkiB! Please try to " + "add more memory to the VM.\n", __func__, mem_chunk_sz[i] >> 10); l4re_debug_obj_debug(l4re_env()->mem_alloc, 0); l4x_exit_l4linux(); then users might realized that using qemu-system-x86_64 -m 1024M to launch L4Linux-mag-x86, and L4Linux is able to run happily :) https://pbs.twimg.com/media/DB3YY0zVwAA9CM9.png sorry for posting screenshots on Twitter but I am so happy! so excited! and my sincere thank goes to you and Jean! you are teaching me patiently and carefully :) -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: Fiasco.OC: null-pointer dereference?
by Leslie Zhai 09 Jun '17

09 Jun '17

Hi Jean, Thanks for your help! 在 2017年06月09日 00:53, Jean Wolter 写道: > On 08/06/17 04:18, Leslie Zhai wrote: >> Hi Matthias, >> >> Jean taught me about how to debug L4Re using jdb in qemu >> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008038.html it >> used a on purpose bug (null ptr deref) to crash Ned, then L4Re >> thrown: unhandled write page fault at 0x0 pc=0x100398d, and addr2line >> ... -e ned -a 100398d to indicate the root cause line. >> >> But how to find out the root cause if unclear that which components >> bring in the issue? > > I think there might be a misunderstanding. I only introduced the null > pointer dereference to demonstrate how to do it using a known problem. > You can apply exactly the same steps in a different situation. I just want to express the ('on purpose' is misuse, sorry for my poor English) debug patch is a demo to guide me how to debug with jdb in the qemu :) you are my mentor teaching me patiently and carefully! > > But I would like to add something. You actually had all the > information you needed: > > MOE: loading 'rom/ned' > Ned says: Hi World! > [1] 0 pf: 0022 pfa=0000000000000018 ip=fffffffff0031ea9 (R-) > spc=0xffffffff807c3dd > [2] L4Re[rm]: unhandled read page fault at 0x18 pc=0x102e893 > [3] L4Re: unhandled exception: pc=0xfffffffff0031ea9 (pfa=18) > L4Re: Global::l4re_aux->ldr_flags=0 > > > In [2] you see the message from the local pager, that is unable to > find a valid region for the pagefault address and complains. It shows > the 0x18 as pagefault address and an instruction pointer 0x102e893. > The instruction pointer did not make any sense at that time. The local > pager triggers an exception. > > In [3] you see the exception message. It shows the instruction pointer > where the pagefault was actually raised: 0xfffffffff0031ea9. This is > an address inside the kernel: That is the key point! it is magic to me that 0xfffffffff0031ea9 is an address inside the kernel, I need to deepinto Fiasco about address space, correct? > ~/build/tmp/l4re$ addr2line -p -i -e > ../leslie/fiasco/build/fiasco.image -a fffffffff0031ea9 > 0xfffffffff0031ea9: > /home/zhaixiang/project/l4re/kernel/fiasco/src/drivers/amd64/processor-amd64.cpp:67 > ... > (inlined by) > /home/zhaixiang/project/l4re/kernel/fiasco/src/kern/ram_quota.cpp:53 > > /home/zhaixiang/project/l4re/kernel/fiasco/src/drivers/amd64/processor-amd64.cpp:67 > fffffffff0031ea8: fa cli > fffffffff0031ea9: 48 8b 47 18 mov 0x18(%rdi),%rax > fffffffff0031ead: 48 03 77 10 add 0x10(%rdi),%rsi > _ZN9Ram_quota5allocEl(): > /home/zhaixiang/project/l4re/kernel/fiasco/src/kern/ram_quota.cpp:54 > > If it is not a kernel fault and you need to find out, which component > is responsible (or need more information about the current state) you > can press 'i' when line [0] appears. You enter the kernel debugger and > can look at the current thread using t<enter>. The thread has an id, > which you can lookup in the list of present threads (using 'lp'). Here > it is thread 22: > > id cpu name pr sp wait to stack state > 2e 0 ----- 2 1e - ( 920) rcv_wait > 2b 0 ----- 10 1e - (1072) rcv_wait > 22 0 ----- 2 1e (1776) ready > 1f 0 #ned ff 1e - (1072) > ready,rcv_wait > > All threads shown here have the same address space and therefore the > problem happened in the context of ned. > >> >> The same story is how to debug L4Linux? >> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008047.html >> please give me some advice, thanks a lot! >> > Maybe you can add "-serial stdio" to your qemu options and provide the > complete backtrace for the problem? It looks like a framebuffer issue, > but there should be more information in the lines above ... I will try instead of posting screenshots on Twitter, sorry for my posting! > > regards, > Jean > -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

1 0

Re: About l4linux debug method
by Leslie Zhai 08 Jun '17

08 Jun '17

Hi L4 hackers, > fiasco r72 applied 0001-Fix-invalid-initialization-in-new.patchhttp://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html l4re r72 and l4linux r54 is not able to workhttps://pbs.twimg.com/media/DBtVv8zXoAAelwt.png <https://pbs.twimg.com/media/DBtVv8zXoAAelwt.png> l4linux-build can be downloaded here https://drive.google.com/open?id=0ByE8c-y74l_uTmtYVnVIbHdRZ0k -- Regards, Leslie Zhai - a LLVM hacker https://reviews.llvm.org/p/xiangzhai/

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers