Devel February 2023

devel@sel4.systems

9 participants
7 discussions

Questions about Memory Management in seL4
by Daniel Wang 19 May '23

19 May '23

Hi all, Sorry to bother, I have some basic questions about seL4 memory management. Can someone help me? 1. where is the kernel’s address space? I know there are basically three methods: a) separate virtual address space, e.g. through changing page tables on entry into privileged mode to access b) physical space, e.g. through disable automatic hardware translation of virtual addresses on entry into privilege mode c) privilege region in each process’s virtual address space, e.g. through page table to map kernel address into use-mode process. My question is which of this is being used by seL4 microkernel? 2. Objects like CSpace, VSpace, CNode, TCB, Endpoint, etc. are called kernel objects, but it seems all dynamically allocated in thread running/creating time. Are those objects (e.g. Figure 3.3 in seL4 manual) in kernel space or in user space? 3. I read that after the kernel boot up, it passes all resources, untyped memory to the first thread. Are those untyped memory physical memory or virtual memory in a single page? The reason I ask is I’m learning the code of the UNSW AOS project (two of the assignment projects are implementing frame and papers). I’m confused that before the implementation of frames and pages what kind of memory is passed to the the first thread? I saw int AOS project, it uses ut_table_init(), ut_steal_mem(), I wonder what kind of memory it operates on? Thanks -Dan

5 4

shoehorn & fudge factor
by Sam Leffler 14 Mar '23

14 Mar '23

I have a target platform with only 4M of memory. When the system image is generated and the shoehorn helper script is used to find a place in memory to load the build artifacts it tacks on an extra 4M of memory use (aka fudge_factor). The comment in the code <https://github.com/AmbiML/sparrow-seL4_tools/blame/master/cmake-tool/helper…> says this is to accommodate sel4test_driver. Needless to say this breaks on my 4M target platform. So I made the fudge-factor settable from the cmd line with a default of 0 and changed the sel4test build glue to set 4M when building elfloader. Works fine for my target platform. But this change breaks building a bootable image for rpi3 (AARCH64=1 bcm28367)--shoehorn places elfloader s.t. it overlaps the image; e.g. ELF-loader started on CPU: ARM Ltd. Cortex-A53 r0p4 > paddr=[335000..51a0ff] > No DTB passed in from boot loader. > Looking for DTB in CPIO archive...found at 378778. > Loaded DTB from 378778. > paddr=[237000..23afff] > ELF-loading image 'kernel' to 0 > paddr=[0..236fff] > vaddr=[ffffff8000000000..ffffff8000236fff] > virt_entry=ffffff8000000000 > ELF-loading image 'capdl-loader' to 23b000 > paddr=[23b000..33bfff] > vaddr=[400000..500fff] > virt_entry=4009a8 > ERROR: image load address overlaps with ELF-loader! > ERROR: Physical address range invalid > ERROR: Could not load user image ELF Debug output of shoehorn for this case: shoehorn: debug: found CPIO identifying sequence b'070701' at offset 0x40 > in > /usr/local/google/home/sleffler/shodan/out/cantrip/aarch64-unknown-elf/release/elfloader/archive.o > shoehorn: debug: encountered CPIO entry name: kernel.elf > shoehorn: debug: encountered CPIO entry name: kernel.dtb > shoehorn: debug: encountered CPIO entry name: capdl-loader > shoehorn: debug: setting marker to 0x0 (region 0 start) > shoehorn: debug: setting marker to 0x237000 (kernel_end) > shoehorn: debug: setting marker to 0x23b000 (dtb_end) > shoehorn: debug: setting marker to 0x335000 (end of rootserver) So two questions: 1. Where is the 4M under-count of sel4test_driver? (the code indicates this might be explained in JIRA SELFOUR-2335 but I couldn't locate it) 2. Should zero'ing fudge_factor work? If yes, where should I look to remedy the above? I looked upstream for changes that might address this issue but didn't see anything. I suspect I can invert my logic and default fudge_factor to some value and then override as needed (e.g. 0 for my sparrow platform & 4M for sel4test builds). -Sam

3 5

UnknownSyscall Exception Handler for non-seL4 syscall API
by lukas-graber＠protonmail.com 28 Feb '23

28 Feb '23

Hello, I am working on a syscall handler in user-space and want to implement a trap-and-emulate like mechanism. Firstly, some background information and motivation. I see that the seL4 system call API uses negative syscall numbers. This allows me theoretically to use positive syscall numbers to implement an additional syscall API. The seL4 kernel triggers an UnknownSyscall Exception whenever it encounters different syscalls and leads it to the fault handler endpoint in user space of the corresponding CAmkES component. I work with CAmkES and was able to create a fault handler similar to the one implemented in GDBMem with the help of templates. I am generally able to catch the exception in a thread in the same component and get the corresponding arguments. What I don't seem to manage is redirecting the program flow of the control thread so that we return to right after the faulting syscall instruction (should be faultIP + 2). It generally just retriggers the same exception or a different one (the VMFault exception). To better understand what I did, I quickly provide the code: - My C code: Triggers the system call number 60 with 6 arguments: ```bash int run(void) { while(1){ register int rax __asm__ ("rax") = 60; register int rdi __asm__("rdi") = 1; register int rsi __asm__("rsi") = 2; register int rdx __asm__("rdx") = 3; register int r10 __asm__("r10") = 4; register int r8 __asm__("r8") = 5; register int r9 __asm__("r9") = 6; __asm__ __volatile__ ( "syscall" : "+r" (rax) : "r" (rdi), "r" (rsi), "r" (rdx), "r" (r10), "r" (r8), "r" (r9) : "rcx", "r11", "memory"); printf("After the syscall instruction!\n"); } } ``` - My CAmkES code: We connect two threads of the component CompA, the faultIn thread is related to the From Template, the faultOut thread is related to the To template. ```bash connector camkesFaultHandlerThread { from Procedure; to Procedure; } procedure CAmkES_FaultHandlerThread { void bla(); } component CompA { control; uses CAmkES_FaultHandlerThread faultIn; provides CAmkES_FaultHandlerThread faultOut; } assembly { composition { component CompA compA; connection camkesFaultHandlerThread fault0 (from compA.faultIn, to compA.faultOut); } } ``` - The to Template: gets triggered with every fault, should handle the system call and then redirect program flow ```bash /*- set fault_ep = alloc("fault", seL4_EndpointObject, read=True, write=True, grantreply=True) -*/ /*- set info = c_symbol('info') -*/ int /*? me.interface.name ?*/__run(void) { seL4_Word fault_type; seL4_Word length; seL4_Word delegate_tcb; seL4_UserContext regs; seL4_MessageInfo_t info; while (1) { info = seL4_Recv(/*? fault_ep ?*/, &delegate_tcb); seL4_Fault_t fault = seL4_getFault(info); fault_type = seL4_MessageInfo_get_label(info); if(fault_type == seL4_Fault_UnknownSyscall){ printf("faulting PC: %zx\n",seL4_Fault_UnknownSyscall_get_FaultIP(fault)); //handle the syscall ... length = seL4_MessageInfo_get_length(info); seL4_TCB_ReadRegisters(delegate_tcb, false, 0, sizeof(seL4_UserContext) / sizeof(seL4_Word), &regs); // Which registers should I set for the faultIn thread?, right now simply jump over the syscall instruction regs.rip += 2; // Write registers back seL4_TCB_WriteRegisters(delegate_tcb, false, 0, sizeof(seL4_UserContext) / sizeof(seL4_Word), &regs); // Resume the caller seL4_MessageInfo_t info = seL4_MessageInfo_new(0, 0, 0, length); seL4_Reply(info); } else if(fault_type = seL4_Fault_VMFault){ // Why do we get in here after replying to UnknownSyscallException? } } } ``` I simply want to handle the UnknownSyscall Exception (in the faultOut thread) and then return to the instruction right after the original syscall in the control thread. But no matter how I change the IP, it just retriggers the exception or causes a VM Fault Exception. I see that there is a NextIP virtual register field in kernel/include/arch/x86/arch/64/mode/machine/registerset.h. Can I somehow set this one from userspace with setRegister? Has anyone ever tried something similar? Help would be very much appreciated. Thank you very much! Kind Regards, Lukas

2 2

Slowpath IPC mechanism
by mincheol＠vt.edu 22 Feb '23

22 Feb '23

Hi, I am wondering how the slowpath IPC mechanism works. Does it use shared memory to transfer the IPC message?

2 1

Reminder seL4 developer hangout
by Birgit Brecknell 21 Feb '23

21 Feb '23

Hi all A friendly reminder that the seL4 developer hangout is on again this week: Tue, Feb 21, 9pm (UTC), Topics: (open) * Sydney: Wed, Feb 22, 8am * Central Europe: Tue, Feb 21, 10pm * US Pacific Time: Tue, Feb 21, 1pm Zoom link: https://unsw.zoom.us/j/82640784431 cheers Birg --- Dr. Birgit Brecknell Project Officer Trustworthy Systems, UNSW, birgit.brecknell(a)unsw.edu.au<mailto:birgit.brecknell@unsw.edu.au> seL4 Foundation, birgit(a)sel4.systems<mailto:birgit@sel4.systems> 0433 880 571 Mon 9am-5pm Wed 9am-12pm Fri 9am-5pm

2 1

Re: U-boot for Raspberry PI
by Michal Podhradsky 08 Feb '23

08 Feb '23

Hello, thank you for prompt replies! I used the default U-boot, however now I am stuck in the next phase of booting - specifically loading and booting the sel4 test image. Following the instructions in the docs ( https://docs.sel4.systems/Hardware/Rpi4.html) I do: *U-Boot> fatload mmc 0 0x10000000 sel4test-driver-image-arm-bcm2711** Reading file would overwrite reserved memory **Failed to load 'sel4test-driver-image-arm-bcm2711* Which is odd. Perhaps the memory map on Rpi has changed recently? Picking another memory location gets me further (although it is unclear that it is a correct location): *U-Boot> fatload mmc 0 0x00008000 sel4test-driver-image-arm-bcm27115164988 bytes read in 235 ms (21 MiB/s)U-Boot> bootefi 0x00008000* Now, the image gets loaded but the boot fails with an seL4 assertion fail: *U-Boot> bootefi 0x00008000Card did not respond to voltage select! : -110No EFI system partitionBooting /sel4test-driver-image-arm-bcm2711ELF-loader started on CPU: ARM Ltd. Cortex-A72 r0p3 paddr=[6603000..ffffffffffffffff] dtb=6af2000Looking for DTB in CPIO archive...found at 674d958.Loaded DTB from 674d958. paddr=[123f000..1245fff]ELF-loading image 'kernel' to 1000000 paddr=[1000000..123efff] vaddr=[ffffff8001000000..ffffff800123efff] virt_entry=ffffff8001000000ELF-loading image 'sel4test-driver' to 1246000 paddr=[1246000..164bfff] vaddr=[400000..805fff] virt_entry=40ef20Enabling MMU and pagingJumping to kernel-image entry point...Bootstrapping kernelavailable phys memory regions: 3 [1000000..3b400000] [40000000..fc000000] [100000000..200000000]reserved virt address space regions: 3 [ffffff8001000000..ffffff800123f000] [ffffff800123f000..ffffff800124556b] [ffffff8001246000..ffffff800164c000]Booting all finished, dropped to user spaceseL4 failed assertion 'isSchedulable(candidate)' at /tmp/kernel/src/kernel/thread.c:371 in function schedulehalting...Kernel entry via Interrupt, irq 0* Any suggestions what am I missing? Regards Michal On Thu, Jan 19, 2023 at 5:53 PM Sudvarg, Marion <msudvarg(a)wustl.edu> wrote: > I have a version of U-boot that works. I would have to go back through > piles of notes to see what I did to make it work, but I can share the file > with you if it's helpful. > > I also had to change config.txt to set the GPU and coprocessor frequency > to a fixed value; I had issues with boot (which is handled by the GPU) and > UART without that. > > Happy to help with the process if you like. > > Marion Sudvarg > Washington University in St. Louis > > -----Original Message----- > From: mpodhradsky(a)galois.com <mpodhradsky(a)galois.com> > Sent: Thursday, January 19, 2023 7:02 PM > To: devel(a)sel4.systems > Subject: [seL4] U-boot for Raspberry PI > > Hello! > > The instructions for building seL4 for Raspberry Pi 3 and 4 mention ask > for a custom compiled U-boot. The note mentions that an automatic revert of > the specified commit no longer works. Is this patched U-boot still > necessary, or will a vanilla version work? If the customization is still > needed, do you have a modified version available? It is not clear how to > modify the recent U-boot, since it has changed significantly. > > Regards > Michal > _______________________________________________ > Devel mailing list -- devel(a)sel4.systems To unsubscribe send an email to > devel-leave(a)sel4.systems >

4 5

Reminder seL4 developer hangout
by Birgit Brecknell 06 Feb '23

06 Feb '23

Hi all A friendly reminder that the seL4 developer hangout is on again this week: Wed, Feb 8, 6am (UTC), Topics: (open) * Sydney: Wed, Feb 8, 5pm * Central Europe: Wed, Feb 8, 7am * US Pacific Time: Tue, Feb 7, 10pm Calendar: https://sel4.systems/contact/ Zoom link: https://unsw.zoom.us/j/82640784431 cheers Birg --- Dr. Birgit Brecknell Project Officer Trustworthy Systems, UNSW, birgit.brecknell(a)unsw.edu.au<mailto:birgit.brecknell@unsw.edu.au> seL4 Foundation, birgit(a)sel4.systems<mailto:birgit@sel4.systems> 0433 880 571 Mon 9am-5pm Wed 9am-12pm Fri 9am-5pm

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Devel February 2023