February 2018 - Devel - lists.sel4.systems

Stuck during invalidate local TLB in Tx2
by Muneeswaran Rajendran 16 Oct '24

16 Oct '24

Hi seL4 Dev team, Can someone explain the reason (share the reference) to invalidate the local TLB during kernel vspace activation as part CPU initialisation. The Tx2 board stuck while performing this operation. As per my understanding both Tx1 and Tx2 are using same A57 core. so the TLB initialisation and invalidation remain same for Tx2 and should not stuck during invalidation.Please correct me if anything wrong here. I understand from that instruction (tlbi vmalle1) which is invalidating stage 1 entries associated to the current VMID. Also from arm mmu code the seL4 setting up (TCR_EL1) TCR register addressing space as 48bit, ASID as 16bit and page table setup 4k granular size. I am using MRS macro to dump the spsr_el1 and dspsr_el0 register to see the state of processor but its throwing synchronous exception. Do we have any other option to dump all the register content to see the state of processor like we have one in 'sel4debug_dump_registers' which is used in sel4test code. Regards, Muneeswaran R

3 4

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

IPC
by tj5527 04 Jul '18

04 Jul '18

Searching on the sel4 repository, I find there is a manual talking about IPC (https://github.com/seL4/seL4/blob/9dba8e67ccb54e207bbec22e25f21c65e5c6a45f/…) In addition to this material, where - particularly source code - would be a good start point to look into IPC design and implementation? Thanks

2 1

How to avoid timeout exceptions in non-buggy server code
by Kelly Dean 02 Mar '18

02 Mar '18

The article “Mixed-criticality support in seL4” at https://lwn.net/Articles/745946/ says seL4's solution to the problem of CPU budget exhaustion while in a non-reentrant shared data-structure server is timeout exceptions. The server might time out by chance, through no fault of its own. A more robust solution is to simply disallow calling any such server that advertises a WCET longer than the client's per-period CPU budget, and when a call is made, have the kernel check whether the client's remaining CPU budget ≥ server's WCET. If it is, then proceed with the call as normal. If it isn't, then verify that the client's per-period CPU budget ≥ server's WCET. If that verification succeeds, then terminate the budget for the client's current period early, and actually enter the server at the beginning of the client's _next_ period. (If the verification fails, then the kernel tells the client that the call is disallowed.) If the server fails to return before exhausting the client's CPU budget, then the server has violated its own WCET, which is a bug. Thus, a non-buggy server will never time out, so timeout exception handlers handle only bugs, not routine system operation. If the server's actual WCET is W, then from the client's point of view, the server's apparent WCET is almost 2W, because the client might make the call with remaining CPU budget X such that X is just barely less than W, in which case the kernel will terminate the client's current budget early (so the client loses X) and enter the server at the beginning of the next period, and the server might then take W to return, making the client wait X+W altogether (plus, of course, the remainder of the period, during which other VMs run). But with seL4's current solution, the server's apparent WCET is even longer than 2W, because the server could run for X, time out, be restarted (taking time R), then run for W, making the client wait X+R+W altogether.

2 5

Camkes limitations
by Sam Chenoweth 01 Mar '18

01 Mar '18

Hi, I like the Camkes (3) tool and believe it is essential for making seL4 accessible for developers. However, I have noticed some unexpected limitations that I believe are either bugs or incomplete features. Issue A: A hierarchical component cannot have a dataport with a custom data type. (However, a non-hierarchical component can have a dataport with a custom data type. Also, a hierarchical component can have a dataport with a built-in data type such as Buf.) Issue B: A dataport provided by a sub-component cannot be exported as a dataport belonging to the hierarchical component that contains it. (However, the export of event notifications from sub-components works just fine.) Attached is the relevant code that demonstrates both issues, which is a contrived example to highlight the issues without other stuff getting in the way. Please note that the code as is compiles just fine, however if you comment and uncomment a few lines of code (as instructed in Duck.camkes, Duckherd.camkes and Duckling.camkes), the issues can be demonstrated (separately) as compile failures. There may be other issues with hierarchical components that I am not yet aware of, as the above issues (unfortunately) have prevented me from experimenting with them further. Could you please acknowledge if these are issues that you are aware of, and if there is likely to be a fix in a future Camkes 4 release? Regards, Dr Samuel Chenoweth Cyber Security Researcher DST Group Note: I would have sent this email from my work email address ( samuel.chenoweth(a)dst.defence.gov.au) however I sent it from my personal address instead because of issues to do with our email gateway. All the contents of this email are UNCLASSIFIED and non-sensitive.

2 1

seL4 in an SGX enclave?
by Corey Richardson 28 Feb '18

28 Feb '18

This is email is me being kinda lazy. Does anyone know how challenging this would actually be to pull off? I'm interested in looking into it, but can't for a while. I feel like it makes sense to bootload some little stub that sets up seL4 as the only enclave in the system. I don't see any reason to have multiple enclaves when using seL4. But, from this, it should be possible to get a good static root of trust remote attestation on Google Cloud. (And also, can finally implement https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attesta…) -- cmr http://octayn.net/ +16038524272

4 4

Fwd: CamkesVM CMA34CR_centos app
by Michal Podhradsky 21 Feb '18

21 Feb '18

Hi Kent, I did a fresh *repo init -u https://github.com/seL4/camkes-vm-manifest <https://github.com/seL4/camkes-vm-manifest> * so I am using the latest default.xml Now I can get a bit further - although still not all the way - here is the full output: https://gist.github.com/podhrmic/bc86178e60fad64ab870ff1fa19992 e3 and then the system as far as I can tell hangs - no serial or VGA output. What could be the cause? Regards M On Mon, Feb 19, 2018 at 4:07 PM, <Kent.Mcleod(a)data61.csiro.au> wrote: > Hi Michal, > > > Which revision of default.xml are you using? Adrian thinks it could be > potentially related to, and fixed by, this commit[1] if you don't have it > yet. > > > Kent > > > [1] https://github.com/seL4/seL4/commit/3d6f4f9bb7bfe42628df > a555601401fa4efcdf2d > > > > ------------------------------ > *From:* Devel <devel-bounces(a)sel4.systems> on behalf of Michal Podhradsky > <mpodhradsky(a)galois.com> > *Sent:* Tuesday, February 20, 2018 9:37 AM > *To:* devel(a)sel4.systems > *Subject:* [seL4] CamkesVM CMA34CR_centos app > > Hi all, > > I have a CM34CR CPU module <https://wiki.sel4.systems/CMA34DBMC> and I am > trying to run the related camkes app on it. > > I choose the centos app: https://github.com/seL4/camkes > -vm/blob/master/apps/vm/cma34cr_centos.camkes > > I am using default camkes vm manifest from https://github.com/seL4/camkes > -vm-manifest. > > Compile with: > > *make clean * > > *make cma34cr_centos_defcondig * > > *make silentoldconfig * > *make* > > And then I create a bootable USB following instructions here > <https://wiki.sel4.systems/Hardware/IA32>. > > Then after I load the kernel and capdl image, I get the following output > on serial: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Boot config: parsing cmdline 'sel4kernel' Boot config: console_port = > 0x3f8 Boot config: debug_port = 0x3f8 Boot config: disable_iommu = false > Detected 1 boot module(s): module #0: start=0xd34000 end=0x3b387e8 > size=0x2e047e8 name='rootserver' Parsing GRUB physical memory map > Physical Memory Region from 0 size 9d400 type 1 Physical Memory Region > from 9d400 size 2c00 type 2 Physical Memory Region from e0000 size > 20000 type 2 Physical Memory Region from 100000 size 1ff00000 type 1 > Adding physical memory region 0x100000-0x20000000 Physical Memory > Region from 20000000 size 200000 type 2 Physical Memory Region from > 20200000 size 1fe04000 type 1 Adding physical memory region > 0x20200000-0x40004000 Physical Memory Region from 40004000 size 1000 > type 2 Physical Memory Region from 40005000 size 64bab000 type 1 Adding > physical memory region 0x40005000-0xa4bb0000 Physical Memory Region > from a4bb0000 size 1400000 type 2 Physical Memory Region from a5fb0000 > size 4a0f000 type 1 Adding physical memory region 0xa5fb0000-0xaa9bf000 > Physical Memory Region from aa9bf000 size 500000 type 2 Physical Memory > Region from aaebf000 size 100000 type 4 Physical Memory Region from > aafbf000 size 40000 type 3 Physical Memory Region from aafff000 size > 1000 type 1 Adding physical memory region 0xaafff000-0xab000000 > Physical Memory Region from ab000000 size 4a00000 type 2 Physical > Memory Region from f0000000 size 4000000 type 2 Physical Memory Region > from feb00000 size 4000 type 2 Physical Memory Region from fec00000 > size 1000 type 2 Physical Memory Region from fed10000 size a000 type 2 > Physical Memory Region from fed1c000 size 4000 type 2 Physical > Memory Region from fee00000 size 1000 type 2 Physical Memory Region > from ffc00000 size 400000 type 2 Physical Memory Region from 100000000 > size 14f600000 type 1 Adding physical memory region 0x100000000-0x24f600000 > Got VBE info in multiboot. Current video mode is 16767 ACPI: RSDP > paddr=0xfe020 ACPI: RSDP vaddr=0xfe020 ACPI: RSDT paddr=0xaafda0c4 ACPI: > RSDT vaddr=0xaafda0c4 Kernel loaded to: start=0x100000 end=0xc17000 > size=0xb17000 entry=0x101269 ACPI: RSDT paddr=0xaafda0c4 ACPI: RSDT > vaddr=0xaafda0c4 ACPI: FADT paddr=0xaaffb000 ACPI: FADT vaddr=0xaaffb000 > ACPI: FADT flags=0x3c6a5 ACPI: DMAR paddr=0xaafde000 ACPI: DMAR > vaddr=0xaafde000 ACPI: IOMMU host address width: 36 ACPI: registering > RMRR entry for region for device: bus=0x0 dev=0x1d fun=0x0 ACPI: > registering RMRR entry for region for device: bus=0x0 dev=0x1a fun=0x0 > ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x14 > fun=0x0 ACPI: registering RMRR entry for region for device: bus=0x0 > dev=0x2 fun=0x0 ACPI: 2 IOMMUs detected ACPI: MADT paddr=0xaaff9000 ACPI: > MADT vaddr=0xaaff9000 ACPI: MADT apic_addr=0xfee00000 ACPI: MADT flags=0x1 > ACPI: MADT_APIC apic_id=0x0 ACPI: MADT_APIC apic_id=0x1 ACPI: MADT_APIC > apic_id=0x2 ACPI: Not recording this APIC, only support 2 ACPI: MADT_APIC > apic_id=0x3 ACPI: Not recording this APIC, only support 2 ACPI: MADT_IOAPIC > ioapic_id=0 ioapic_addr=0xfec00000 gsib=0 ACPI: MADT_ISO bus=0 source=0 > gsi=2 flags=0x0 ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xd ACPI: 2 > CPU(s) detected ELF-loading userland images from boot modules: > size=0x41fc000 v_entry=0x409000 v_start=0x400000 v_end=0x45fc000 > p_start=0x3b39000 p_end=0x7d35000 Moving loaded userland images to final > location: from=0x3b39000 to=0xc17000 size=0x41fc000 Starting node #0 with > APIC ID 0 Mapping kernel window is done ========== KERNEL EXCEPTION > ========== Vector: 0xd ErrCode: 0x0 IP: 0xffffffff80115c04 SP: > 0xffffffff80a0bfa0 FLAGS: 0x10046 CR0: 0x80010013 CR2: 0x0 > (page-fault address) CR3: 0xa12000 (page-directory physical address) > CR4: 0x110668 Stack Dump: *0xffffffff80a0bfa0 == 0x0 > *0xffffffff80a0bfa8 == 0x0 *0xffffffff80a0bfb0 == 0x3b39000 > *0xffffffff80a0bfb8 == 0xffffffff80116b80 *0xffffffff80a0bfc0 == 0x0 > *0xffffffff80a0bfc8 == 0x22a8 *0xffffffff80a0bfd0 == 0x0 > *0xffffffff80a0bfd8 == 0x0 *0xffffffff80a0bfe0 == 0xffffffff80000000 > *0xffffffff80a0bfe8 == 0x7e000 *0xffffffff80a0bff0 == 0xaa24c70c > *0xffffffff80a0bff8 == 0x1f *0xffffffff80a0c000 == 0xfffffffff000ba86 > *0xffffffff80a0c008 == 0xffffffff8081f0c0 *0xffffffff80a0c010 == 0x0 > *0xffffffff80a0c018 == 0x0 *0xffffffff80a0c020 == 0x0 *0xffffffff80a0c028 > == 0x0 *0xffffffff80a0c030 == 0x0 *0xffffffff80a0c038 == 0x0 Halting... > halting... Kernel entry via Interrupt, irq 0 * > > Any pointers at what is the cause of error here? The machien runs normally > with vanilla CentOS so I don't think it is a hardware issue. Also, I am > assuming the CMA34CR is identical to the one you have on your side (at > least checking the lspci output against the camkes description the memory > regions etc seem to match). > > Thanks in advance. > M >

3 3

split.c bootstrap.c failure?
by Richard Clark 21 Feb '18

21 Feb '18

Hi! What is this error and how might I go about tracking down the cause? <<seL4(CPU 0) [decodeUntypedInvocation/167 T0xe0792100 "csm-threads" @3a98c]: Untyped Retype: Slot #15 in destination window non-empty.>> _refill_pool@split.c:177 Failed to retype untyped, error 8 vka_alloc_object_at_maybe_dev@object.h:59 Failed to allocate object of size 4096, error 1 alloc_and_map@bootstrap.c:103 Failed to allocate bootstrap frame, error: 1 What I've done, is taken over the usual sel4test process and turned it into a little process that starts a few others. This error occurs at near the beginning of the main process, after it has allocated some untyped space for a secondary process, and just started it running. There is tons of memory available everywhere, and I do not understand why this is failing.... clues? Thanks! Richard H. Clark ________________________________ This message and all attachments are PRIVATE, and contain information that is PROPRIETARY to Intelligent Automation, Inc. You are not authorized to transmit or otherwise disclose this message or any attachments to any third party whatsoever without the express written consent of Intelligent Automation, Inc. If you received this message in error or you are not willing to view this message or any attachments on a confidential basis, please immediately delete this email and any attachments and notify Intelligent Automation, Inc.

2 1

CamkesVM CMA34CR_centos app
by Michal Podhradsky 21 Feb '18

21 Feb '18

Hi all, I have a CM34CR CPU module <https://wiki.sel4.systems/CMA34DBMC> and I am trying to run the related camkes app on it. I choose the centos app: https://github.com/seL4/camkes-vm/blob/master/apps/vm/cma34cr_centos.camkes I am using default camkes vm manifest from https://github.com/seL4/camkes-vm-manifest. Compile with: *make clean* *make cma34cr_centos_defcondig* *make silentoldconfig* *make* And then I create a bootable USB following instructions here <https://wiki.sel4.systems/Hardware/IA32>. Then after I load the kernel and capdl image, I get the following output on serial: *Boot config: parsing cmdline 'sel4kernel'Boot config: console_port = 0x3f8Boot config: debug_port = 0x3f8Boot config: disable_iommu = falseDetected 1 boot module(s): module #0: start=0xd34000 end=0x3b387e8 size=0x2e047e8 name='rootserver'Parsing GRUB physical memory map Physical Memory Region from 0 size 9d400 type 1 Physical Memory Region from 9d400 size 2c00 type 2 Physical Memory Region from e0000 size 20000 type 2 Physical Memory Region from 100000 size 1ff00000 type 1Adding physical memory region 0x100000-0x20000000 Physical Memory Region from 20000000 size 200000 type 2 Physical Memory Region from 20200000 size 1fe04000 type 1Adding physical memory region 0x20200000-0x40004000 Physical Memory Region from 40004000 size 1000 type 2 Physical Memory Region from 40005000 size 64bab000 type 1Adding physical memory region 0x40005000-0xa4bb0000 Physical Memory Region from a4bb0000 size 1400000 type 2 Physical Memory Region from a5fb0000 size 4a0f000 type 1Adding physical memory region 0xa5fb0000-0xaa9bf000 Physical Memory Region from aa9bf000 size 500000 type 2 Physical Memory Region from aaebf000 size 100000 type 4 Physical Memory Region from aafbf000 size 40000 type 3 Physical Memory Region from aafff000 size 1000 type 1Adding physical memory region 0xaafff000-0xab000000 Physical Memory Region from ab000000 size 4a00000 type 2 Physical Memory Region from f0000000 size 4000000 type 2 Physical Memory Region from feb00000 size 4000 type 2 Physical Memory Region from fec00000 size 1000 type 2 Physical Memory Region from fed10000 size a000 type 2 Physical Memory Region from fed1c000 size 4000 type 2 Physical Memory Region from fee00000 size 1000 type 2 Physical Memory Region from ffc00000 size 400000 type 2 Physical Memory Region from 100000000 size 14f600000 type 1Adding physical memory region 0x100000000-0x24f600000Got VBE info in multiboot. Current video mode is 16767ACPI: RSDP paddr=0xfe020ACPI: RSDP vaddr=0xfe020ACPI: RSDT paddr=0xaafda0c4ACPI: RSDT vaddr=0xaafda0c4Kernel loaded to: start=0x100000 end=0xc17000 size=0xb17000 entry=0x101269ACPI: RSDT paddr=0xaafda0c4ACPI: RSDT vaddr=0xaafda0c4ACPI: FADT paddr=0xaaffb000ACPI: FADT vaddr=0xaaffb000ACPI: FADT flags=0x3c6a5ACPI: DMAR paddr=0xaafde000ACPI: DMAR vaddr=0xaafde000ACPI: IOMMU host address width: 36 ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x1d fun=0x0 ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x1a fun=0x0 ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x14 fun=0x0 ACPI: registering RMRR entry for region for device: bus=0x0 dev=0x2 fun=0x0ACPI: 2 IOMMUs detectedACPI: MADT paddr=0xaaff9000ACPI: MADT vaddr=0xaaff9000ACPI: MADT apic_addr=0xfee00000ACPI: MADT flags=0x1ACPI: MADT_APIC apic_id=0x0ACPI: MADT_APIC apic_id=0x1ACPI: MADT_APIC apic_id=0x2ACPI: Not recording this APIC, only support 2ACPI: MADT_APIC apic_id=0x3ACPI: Not recording this APIC, only support 2ACPI: MADT_IOAPIC ioapic_id=0 ioapic_addr=0xfec00000 gsib=0ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0ACPI: MADT_ISO bus=0 source=9 gsi=9 flags=0xdACPI: 2 CPU(s) detectedELF-loading userland images from boot modules:size=0x41fc000 v_entry=0x409000 v_start=0x400000 v_end=0x45fc000 p_start=0x3b39000 p_end=0x7d35000Moving loaded userland images to final location: from=0x3b39000 to=0xc17000 size=0x41fc000Starting node #0 with APIC ID 0Mapping kernel window is done========== KERNEL EXCEPTION ==========Vector: 0xdErrCode: 0x0IP: 0xffffffff80115c04SP: 0xffffffff80a0bfa0FLAGS: 0x10046CR0: 0x80010013CR2: 0x0 (page-fault address)CR3: 0xa12000 (page-directory physical address)CR4: 0x110668Stack Dump:*0xffffffff80a0bfa0 == 0x0*0xffffffff80a0bfa8 == 0x0*0xffffffff80a0bfb0 == 0x3b39000*0xffffffff80a0bfb8 == 0xffffffff80116b80*0xffffffff80a0bfc0 == 0x0*0xffffffff80a0bfc8 == 0x22a8*0xffffffff80a0bfd0 == 0x0*0xffffffff80a0bfd8 == 0x0*0xffffffff80a0bfe0 == 0xffffffff80000000*0xffffffff80a0bfe8 == 0x7e000*0xffffffff80a0bff0 == 0xaa24c70c*0xffffffff80a0bff8 == 0x1f*0xffffffff80a0c000 == 0xfffffffff000ba86*0xffffffff80a0c008 == 0xffffffff8081f0c0*0xffffffff80a0c010 == 0x0*0xffffffff80a0c018 == 0x0*0xffffffff80a0c020 == 0x0*0xffffffff80a0c028 == 0x0*0xffffffff80a0c030 == 0x0*0xffffffff80a0c038 == 0x0Halting...halting...Kernel entry via Interrupt, irq 0* Any pointers at what is the cause of error here? The machien runs normally with vanilla CentOS so I don't think it is a hardware issue. Also, I am assuming the CMA34CR is identical to the one you have on your side (at least checking the lspci output against the camkes description the memory regions etc seem to match). Thanks in advance. M

2 2

CamkesVM: EthDriver and Firewall
by Michal Podhradsky 16 Feb '18

16 Feb '18

Hi all, I have some clarifying questions about the Ethernet driver <https://github.com/seL4/camkes-vm/tree/master/components/Ethdriver> and the Firewall <https://github.com/seL4/camkes-vm/tree/master/components/Firewall> components. 1. Does the ethernet driver return a raw ethernet frame and the consumer of the data has to strip the MAC header etc or does the driver return only payload (IP, ARP etc data)? 2. has the Firewall component been tested and does it work? (I know it is a part of CMA34_centos_defconfig but I don't have a way to test it right now) Thanks for the info. M

2 1