- l4-hackers - example.com Site

Get instruction opcode + operands for page fault
by Josef Stark 04 Feb '18

04 Feb '18

Hi all, when a page fault occurs, does the Instruction Register contain the actual instruction that caused the fault or the previous instruction? In the former case, how can I access it? I need the opcode + the operands (like source/target registers). I already have the memory address that the instruction tried to access. I'm on ARM A9, so only load/store instructions can cause a page fault. I know that I could also look at the address where my IP is pointing to and get the instruction from there, but I'm wondering which way would be easier/better. Cheers, Josef

2 1

Build problems on i386 (Fiasco-OC.UX)
by Paul Boddie 30 Jan '18

30 Jan '18

Hello, More awkward news from Debian on i386! I was looking to build the "Linux Usermode Platform" variant of Fiasco-OC on i386 (well, Pentium 4) and encountered a couple of issues. Firstly, "struct ucontext" is mentioned in src/kern/ux/usermode.cpp but has been deprecated in favour of "ucontext_t". There are some User Mode Linux reports about this: https://lkml.org/lkml/2017/11/15/159 https://lkml.org/lkml/2018/1/25/522 A search-and-replace involving the two terms fixes the compilation error that otherwise occurs. Secondly, linking of the kernel fails due to symbol conflicts between the minilibc functionality and glibc: /usr/lib/gcc/i686-linux-gnu/6/../../../i386-linux-gnu/libc.a(memcmp.o): In function `memcmp': (.text+0x0): multiple definition of `memcmp' libc.a(memcmp.o):/home/paulb/L4/UX-75/src/kernel/fiasco/src/lib/minilibc/memcmp.c:7: first defined here collect2: error: ld returned 1 exit status /home/paulb/L4/UX-75/src/kernel/fiasco/src/kern/ux/Makerules.KERNEL:35: recipe for target 'fiasco.debug' failed So, not knowing how best to deal with this, I relied on the --allow-multiple- definition linker option: https://gcc.gnu.org/ml/gcc-help/2009-09/msg00108.html I doubt that this is the right way to deal with it. Maybe GCC 6.4 (Debian 6.4.0-12) introduced some behaviour that is not compatible with the way this linking is being done. Both of the above issues are present in repository versions 74, 75 and 76 at the very least. Certainly, the first issue is not likely to be absent in earlier versions. Paul P.S. I have also been experiencing a build problem with L4Re on i386, but this will be described in another message.

2 2

Build problems on i386 (L4Re)
by Paul Boddie 30 Jan '18

30 Jan '18

As promised, my other error report... With Fiasco-OC built, I concentrated on building L4Re for i386, but this led to me encountering this rather frustrating error: [l4util] ==> Linking to shared libl4util.so /home/paulb/L4/UX-75/src/l4/mk/lib.mk:139: recipe for target 'libl4util.so' failed make[4]: *** [libl4util.so] Segmentation fault make[4]: *** Deleting file 'libl4util.so' ../../../../../mk/binary.inc:164: recipe for target '/home/paulb/L4/UX-75/src/l4/mybuild/pkg/l4re-core/l4util/lib/src/OBJ-x86_gen- l4f' failed This issue is present in repository versions 72 through 76. Again, I'm testing this with GCC 6.4 (Debian 6.4.0-12). I've not seen this at all when cross- compiling, either with the Debian or with Buildroot compilers. Paul

2 2

OS Engineers Wanted!
by Gernot Heiser 30 Jan '18

30 Jan '18

[Apology for the shameless ad, but might be of interest to some] Would you like to get paid for making the world more secure with seL4? I'm in charge of directing OS development for the newly-founded company Hensoldt Cyber. We will develop an integrated, highly-secure hardware-software solution, combined with secure production, aimed at changing the game in securing real-world embedded/cyber-physical systems. Needless to say, there will be close collaboration with the Data61 Trustworthy Systems team. We're now hiring engineers who will help us getting there. Specifically, we're looking for strongly-motivated people with practical experience in OS development, although there is flexibility with the degree of experience. Actual experience with L4 microkernels would be awesome. Place of work will be Munich (no remote work possible, sorry). You'll have to be prepared to obtain a German government security clearance (German citizenship is not a requirement for this). Interested? Please send me your CV. Gernot

1 0

Access ARM Data Fault Address Register (System Control Register) in Fiasco.OC
by Stark, Josef 26 Jan '18

26 Jan '18

Hey, in Fiasco.OC we have a function inside src/kernel/foc/l4/pkg/l4sys/include/thread.h > L4_INLINE l4_msgtag_t > l4_thread_ex_regs_ret(l4_cap_idx_t thread, l4_addr_t *ip, l4_addr_t *sp, > l4_umword_t *flags) L4_NOTHROW; which allows us for a given thread (capability ID) to read its general purpose registers, SP and IP. Is there a similar function (if not, how could I achieve it) to access the ARM A9 System control registers or, to be more precise, the Data Fault Address Register (DFAR) [1] of a thread? I tried creating a function similar to the above mentioned, but modified the body to do this: > unsigned int v; > asm volatile ("mrc p15, 0, %[v], c6, c0, 0" : [v]"=r"(v) :: ); and then write v back to the caller. But this just made the whole system hang. Any ideas? Thanks in advance! Best regards, Josef [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100511_0401_10_…

3 3

L4/Fiasco kernel debugger (jdb) and step over command
by Valery V. Sedletski 21 Jan '18

21 Jan '18

Hi. I'm trying to debug my program with jdb. (I'm using the old L4/Fiasco / L4Env, not the current Fiasco.OC / L4Re). I enabled the permanent single step mode (with the S+ command) and a permanent show the Thread Control Block (with the t+ command) option. So, I was able to single-step with "g" command. Also, I found "jr" (go until return (ret or iret) is encountered) and "jb" (go until the next branch instruction, like jmp/call/int) commands, but they don't seem to work. When I enter them, I see only a single step to the next instruction. Are these two commands broken? How do I step over a "call"/"int" instruction? Thanks in advance, valery

3 11

Re: Question about vm memory initialization
by nico 11 Jan '18

11 Jan '18

2 2

Workaround to build l4linux for ARM Target
by Leslie Zhai 10 Jan '18

10 Jan '18

Hi l4 hackers, ../arch/l4/arm-mach-l4/l4.c:33:10: fatal error: l4/io/io.h: No such file or directory #include <l4/io/io.h> ^~~~~~~~~~~~ compilation terminated. so I just workaround to `ln -s` manually: build-freescale-imx6/include/l4/io/ ├── io.h -> /data/project/xiangzhai/l4re/l4/pkg/io/libio-io/include/io.h ├── pciids.h -> /data/project/xiangzhai/l4re/l4/pkg/io/io/server/libpciids/include/pciids.h └── types.h -> /data/project/xiangzhai/l4re/l4/pkg/io/libio-io/include/types.h l4re version: svn76 l4linux version: svn57 GNU toolchain: gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11) I think it might be `Makefile` simple issue :) -- Regards, Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

2 3

Question about vm memory initialization
by nico 10 Jan '18

10 Jan '18

Hi Adam, I started uvmm and found that all ram space allocated to vm are cleared. But I do not need to do that, because uboot has loaded image file to ram, and vm linux would use that image file. Could you tell me where the uvmm did the cleanup? Regards, Nico

4 3

L4Re and Meltdown / Spectre attacks
by Matthias Lange 08 Jan '18

08 Jan '18

Hi, after the dust around the Meltdown and Spectre attacks has settled a bit, you may wonder how Fiasco.OC / L4Re fares with regard to these attacks. Fiasco.OC / L4Re is vulnerable to Meltdown-like attacks because the kernel is mapped into each task. However, the kernel does not map all physical memory but only memory it requires for its own data structures + kernel-user memory required for e.g. UTCBs and vCPU state save areas. Depending on the amount of physical memory and the available page sizes, Fiasco.OC may map it little bit more than that to save TLB entries. That means there can be a slight overlap of user memory that is visible to the kernel. But it is not possible for a thread to read _all_ memory. Because we think that no thread should read information from other threads (pagetables, capability arrays, UTCBs etc.), we plan to change Fiasco.OC to execute in its own address space on Intel CPUs. Against Spectre we do not plan to implement anything right now. We think the attack surface of the kernel is very little (if any) and may be even further reduced with Intel's microcode updates and future compiler/tool mitigations. However, we will observe future discussions and developments and may reassess this in the future. Thank you and regards, Matthias. -- Kernkonzept GmbH. Sitz: Dresden. Amtsgericht Dresden, HRB 31129. Geschäftsführer: Dr.-Ing. Michael Hohmuth

1 0