March 2018 - Devel - lists.sel4.systems

ARM-VM with Linux Distribution
by Daniel Wang 06 Mar '18

06 Mar '18

Hi all, I was able to compile the camkes-arm-vm and run it on a TK1-SOM board. I wonder if it is possible to run a Linux distribution as the guest OS, such as Ubuntu, Fedora, etc.? If so how can we do that? Best Regards -Daniel Wang

2 1

Re: [seL4] seL4 VMM Hangs during loading time
by Daniel Wang 02 Mar '18

02 Mar '18

Hi Kent and Peter, Thank you so much for your response. I do not know what exactly caused the issue. But I upgraded my toolchain and recompiled the image again and it loaded this time. The GCC version is version 7.2.1 (before it was 4.6). Although I still see the misaligned information like this: CACHE: Misaligned operation at range [90000000, 90000014] CACHE: Misaligned operation at range [90001000, 900091c4] CACHE: Misaligned operation at range [900091c4, 900098d8] CACHE: Misaligned operation at range [900198d8, 900198e0] CACHE: Misaligned operation at range [900198e0, 91392ae0] CACHE: Misaligned operation at range [91394000, 913a4820] CACHE: Misaligned operation at range [913a4820, 913a8000] Another thing I found is that U-boot for TK1-SOM cannot detect ethernet, but I was able to copy the image into MMC and load from there. There are two things I want to do with the seL4 ARM VMM platform. First, I want to incorporate the secure boot from U-boot to seL4 and then using seL4 to verified signed Linux. Second, I want to build a PoC native application and allow the communication between the native app to communication with App running in Linux. I’m wondering if anyone did those two things before that can give me some advice? I implemented the the second scenario before using L4re with a paravirtualized L4Linux. But I’m exactly sure how to do it with seL4 yet. Best Regards -Daniel Wang > On Mar 1, 2018, at 8:00 PM, <Kent.Mcleod(a)data61.csiro.au> <Kent.Mcleod(a)data61.csiro.au> wrote: > > Hi Daniel, > > Two things to try: > > First is to confirm that CONFIG_PRINTING is enabled to distinguish if the kernel is successfully starting its init process. > > Second is to check what ${loadaddr} is set to. Yours seems correct, ours seems to be 0x81000000, but that is for the tk1 jetson dev board. > > You could also try editing the elfloader to print out the contents of the kernel entrypoint before it jumps there to confirm that it is the correct instructions in the stage/arm/tk1/kernel.elf binary. > > Below is what I see when I boot the project on our devboard. > > Kind regards, > Kent. > > ---- > U-Boot SPL 2015.10-rc5-00002-gf861f51-dirty (Oct 13 2015 - 13:44:41) > > > U-Boot 2015.10-rc5-00002-gf861f51-dirty (Oct 13 2015 - 13:44:41 +1100) > > TEGRA124 > Model: NVIDIA Jetson TK1 > Board: NVIDIA Jetson TK1 > DRAM: 2 GiB > MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1 > tegra-pcie: PCI regions: > tegra-pcie: I/O: 0x12000000-0x12010000 > tegra-pcie: non-prefetchable memory: 0x13000000-0x20000000 > tegra-pcie: prefetchable memory: 0x20000000-0x40000000 > tegra-pcie: 2x1, 1x1 configur��K��Ʌ�pcie: probing port 0, using 2 lanes > tegra-pcie: link 0 down, retrying > tegra-pcie: link 0 down, retrying > tegra-pcie: link 0 down, retrying > tegra-pcie: link 0 down, ignoring > tegra-pcie: probing port 1, using 1 lanes > In: serial > Out: serial > Err: serial > Net: RTL8169#0 > Hit any key to stop autoboot: 2 > 0 > Tegra124 (Jetson TK1) # setenv autoload no && dhcp && tftpboot 0x81000000 jetson1/sel4-image > setenv autoload no && dhcp && tftpboot 0x81000000 jetson1/sel4-image > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > DHCP client bound to address 10.13.1.172 (2929 ms) > Using RTL8169#0 device > TFTP from server 10.13.0.130; our IP address is 10.13.1.172 > Filename 'jetson1/sel4-image'. > Load address: 0x81000000 > Loading: ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################ > 3.8 MiB/s > done > Bytes transferred = 20493516 (138b4cc hex) > Tegra124 (Jetson TK1) # bootelf 0x81000000 > bootelf 0x81000000 > ## Starting application at 0x90000000 ... > ELF loader: monitor mode init done > Copy monitor mode vector from 90001000 to a7f00000 size 50 > Number of IRQs: 192 > Load seL4 in nonsecure HYP mode 600001da > ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3 > paddr=[90000000..9139ffff] > ELF-loading image 'kernel' > paddr=[80000000..8003cfff] > vaddr=[e0000000..e003cfff] > virt_entry=e0000000 > ELF-loading image 'capdl-loader-experimental' > paddr=[8003d000..8158dfff] > vaddr=[10000..1560fff] > virt_entry=18484 > Enabling hypervisor MMU and paging > Jumping to kernel-image entry point... > > Bootstrapping kernel > Total 28 IOASID set up > Region [c to 28) for SMMU caps > Booting all finished, dropped to user space > > > > From: Devel <devel-bounces(a)sel4.systems> on behalf of Daniel Wang <danielwang.ksu(a)gmail.com> > Sent: Friday, March 2, 2018 7:47 AM > To: devel(a)sel4.systems > Subject: [seL4] seL4 VMM Hangs during loading time > > Hi all, > > I’m trying to run seL as a microvisor following the CAMKES-ARM-VM. My development board is TK1-SOM from ColoradoEngineering. I was able to flash the U-boot to to load seL4 HYP mode. However when I try to load the kernel. The system just hangs. I got stuck here any help would be appreciated thank you! > > I built the capdl-loader-experimental-image-arm-tk1 > and can copied it to the TK1 MMC storage, then I followed the wiki to setup env bootm_boot_mode to nonsec. Attachment is the printout: > > ------------------------------------------------------------------------------------------- > U-Boot 2018.03-rc3-00090-g3990c9d (Mar 01 2018 - 14:33:40 -0500) > > TEGRA124 > Model: Colorado Engineering TK1-SOM > Board: CEI tk1-som > DRAM: 2 GiB > MMC: sdhci@700b0400: 1, sdhci@700b0600: 0 > Loading Environment from MMC... OK > In: > serial > Out: serial > Err: serial > Net: No ethernet found. > Hit any key to stop autoboot: 0 > Tegra124 (TK1-SOM) # setenv bootm_boot_mode nonsec > Tegra124 (TK1-SOM) # saveenv > Saving Environment to MMC... Writing to MMC(0)... OK > Tegra124 (TK1-SOM) # ext2ls mmc 0 > <DIR> > 4096 . > <DIR> > 4096 .. > <DIR> > 16384 lost+found > <DIR> > 4096 boot > <DIR> > 4096 bin > <DIR> > 4096 dev > <DIR> > 12288 etc > <DIR> > 4096 home > <DIR> > 4096 lib > <DIR> > 4096 media > <DIR> > 4096 mnt > <DIR> > 4096 opt > <DIR> > 4096 proc > > 62 README.txt > <DIR> > 4096 root > <DIR> > 4096 run > <DIR> > 12288 sbin > <DIR> > 4096 srv > <DIR> > 4096 sys > <DIR> > 4096 tmp > <DIR> > 4096 usr > <DIR> > 4096 var > > 150994944 testfile > > 20524388 capdl-loader-experimental-image-arm-tk1 > Tegra124 (TK1-SOM) # ext2load mmc 0 ${loadaddr} capdl-loader-experimental-image-arm-tk1 > 20524388 bytes read in 593 ms (33 MiB/s) > Tegra124 (TK1-SOM) # bootelf ${loadaddr} > CACHE: Misaligned operation at range [90000000, 90000014] > CACHE: Misaligned operation at range [90001000, 900091c4] > CACHE: Misaligned operation at range [900091c4, 900098d8] > CACHE: Misaligned operation at range [900198d8, 900198e0] > CACHE: Misaligned operation at range [900198e0, 91392ae0] > CACHE: Misaligned operation at range [91394000, 913a4820] > CACHE: Misaligned operation at range [913a4820, 913a8000] > ## Starting application at 0x90000000 ... > ELF loader: monitor mode init done > Copy monitor mode vector from 90001000 to a7f00000 size 50 > Number of IRQs: 192 > Load seL4 in nonsecure HYP mode 600001da > ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3 > paddr=[90000000..913a7fff] > ELF-loading image 'kernel' > paddr=[60000000..6003cfff] > vaddr=[e0000000..e003cfff] > virt_entry=e0000000 > > ------------------------------------------------------------------------------------------- > > Best Regards > -Daniel Wang > > > >

1 0

seL4 VMM Hangs during loading time
by Daniel Wang 02 Mar '18

02 Mar '18

Hi all, I’m trying to run seL as a microvisor following the CAMKES-ARM-VM. My development board is TK1-SOM from ColoradoEngineering. I was able to flash the U-boot to to load seL4 HYP mode. However when I try to load the kernel. The system just hangs. I got stuck here any help would be appreciated thank you! I built the capdl-loader-experimental-image-arm-tk1 and can copied it to the TK1 MMC storage, then I followed the wiki to setup env bootm_boot_mode to nonsec. Attachment is the printout: ------------------------------------------------------------------------------------------- U-Boot 2018.03-rc3-00090-g3990c9d (Mar 01 2018 - 14:33:40 -0500) TEGRA124 Model: Colorado Engineering TK1-SOM Board: CEI tk1-som DRAM: 2 GiB MMC: sdhci@700b0400: 1, sdhci@700b0600: 0 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Tegra124 (TK1-SOM) # setenv bootm_boot_mode nonsec Tegra124 (TK1-SOM) # saveenv Saving Environment to MMC... Writing to MMC(0)... OK Tegra124 (TK1-SOM) # ext2ls mmc 0 <DIR> 4096 . <DIR> 4096 .. <DIR> 16384 lost+found <DIR> 4096 boot <DIR> 4096 bin <DIR> 4096 dev <DIR> 12288 etc <DIR> 4096 home <DIR> 4096 lib <DIR> 4096 media <DIR> 4096 mnt <DIR> 4096 opt <DIR> 4096 proc 62 README.txt <DIR> 4096 root <DIR> 4096 run <DIR> 12288 sbin <DIR> 4096 srv <DIR> 4096 sys <DIR> 4096 tmp <DIR> 4096 usr <DIR> 4096 var 150994944 testfile 20524388 capdl-loader-experimental-image-arm-tk1 Tegra124 (TK1-SOM) # ext2load mmc 0 ${loadaddr} capdl-loader-experimental-image-arm-tk1 20524388 bytes read in 593 ms (33 MiB/s) Tegra124 (TK1-SOM) # bootelf ${loadaddr} CACHE: Misaligned operation at range [90000000, 90000014] CACHE: Misaligned operation at range [90001000, 900091c4] CACHE: Misaligned operation at range [900091c4, 900098d8] CACHE: Misaligned operation at range [900198d8, 900198e0] CACHE: Misaligned operation at range [900198e0, 91392ae0] CACHE: Misaligned operation at range [91394000, 913a4820] CACHE: Misaligned operation at range [913a4820, 913a8000] ## Starting application at 0x90000000 ... ELF loader: monitor mode init done Copy monitor mode vector from 90001000 to a7f00000 size 50 Number of IRQs: 192 Load seL4 in nonsecure HYP mode 600001da ELF-loader started on CPU: ARM Ltd. Cortex-A15 r3p3 paddr=[90000000..913a7fff] ELF-loading image 'kernel' paddr=[60000000..6003cfff] vaddr=[e0000000..e003cfff] virt_entry=e0000000 ------------------------------------------------------------------------------------------- Best Regards -Daniel Wang

3 2

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