- Devel - lists.sel4.systems

seL4 cache pinning
by 송대영 02 Dec '18

02 Dec '18

Hi, I read "Improving Interrupt Response Time in a Verifiable Protected Microkernel" paper. This paper improved IPC performance by using cache pinning and I want to know how to implement cache pinnng. But this paper doesn't refer how to manipulate cache lines. Would you give me some methods how to read cache lines and write cache lines?

3 2

Is the ASID used in seL4 by default?
by Dd Nirvana 02 Dec '18

02 Dec '18

Hi guys, I found that seL4's ARM version still need "isb" and "dsb" around updating TTBR0_EL1. This fence will flush the TLB and will affect IPC performance. However, it seems that enabling ASID can avoid this costs. I am not sure, is there any concern that makes seL4 to avoid using ASID? BTW, I have seen ASID management in seL4 (ASID control and ASID pool), so maybe I misunderstood something? Dong Du, Shanghai Jiao Tong University

2 1

sel4bench config problem
by 송대영 23 Nov '18

23 Nov '18

Hi, I have a sel4bench config problem. I use 'ccmake ..' command to configure sel4 configuration but system prints error with this message. Build files have been written to: /home/scribnote5/sel4bench_thesis/build CMake Warning at tools/seL4/cmake-tool/flags.cmake:123 (message): Kernel supports hardware floating point but toolchain does not Call Stack (most recent call first): tools/seL4/cmake-tool/base.cmake:58 (include) tools/seL4/cmake-tool/all.cmake:18 (include) CMakeLists.txt:21 (include) Please help me!

2 1

seL4 stack overflow
by Anna.Lyons＠data61.csiro.au 21 Nov '18

21 Nov '18

Hi everyone, I've created a proposal for an seL4 stack overflow, which will complement the mailing list. Please support it! https://area51.stackexchange.com/proposals/120611/sel4?referrer=oNjnX5y9POx… Cheers, Anna.

2 1

seL4 on Raspberry 3
by talos 19 Nov '18

19 Nov '18

Hi Did anyone try seL3 on raspberry pi 3? I tried following these links:https://research.csiro.au/tsblog/sel4-raspberry-pi-3/ https://docs.sel4.systems/Hardware/Rpi3.html https://inner-haven.net/posts/2017-09-15-sel4-rpi3.html#fnref1 I set the serial port 115200, 8N1, but I only got some messy codes, I did not get the booting information! Did anyone find this cases? Thanks Sincerely

2 1

Re: [seL4] seL4 10.1.0 and camkes-3.6.0
by jonas.cl＠protonmail.com 15 Nov '18

15 Nov '18

Hi, Today I created a few pull-requests on seL4 repos to build x86-64 with clang: - https://github.com/seL4/seL4/pull/105 - https://github.com/seL4/musllibc/pull/4 - https://github.com/seL4/seL4_tools/pull/19 /Jonas ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, November 14, 2018 5:28 PM, <devel-request(a)sel4.systems> wrote: > Message: 3 > Date: Wed, 14 Nov 2018 16:28:17 +0000 > From: Andy Helten andy.helten(a)goctsi.com > To: "Matthew.Brecknell(a)data61.csiro.au" > Matthew.Brecknell(a)data61.csiro.au, "devel(a)sel4.systems" > > <devel(a)sel4.systems> > > > Subject: Re: [seL4] seL4 10.1.0 and camkes-3.6.0 > Message-ID: > DM6PR17MB2314D1EF141DD6DD6A4779BE92C30(a)DM6PR17MB2314.namprd17.prod.outlook.com > > Content-Type: text/plain; charset="utf-8" > > Disclaimer: I've never compiled sel4 nor executed sel4 and, at this point, am just a follower of this mailing list (with tentative plans to use sel4 "someday") > > Regarding the issue that was fixed here, my first thought was "why did the compiler not complain?". My next thought was "maybe sel4 doesn't enable all warnings in their builds or they ignore the warnings!" But surely a kernel that focuses on security would enable all compiler warnings and fix them immediately as they are introduced. > > Turns out it doesn't matter what sel4 builds are doing, the gcc compiler has a bug that prevents warnings for several of these common "might be used uninitialized" cases. See here: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 > > It also appears this bug will not be fixed! An alternative for some projects, though maybe not sel4, is to also compile their code with clang, which does catch these uninitialized cases. If sel4 can use clang to catch these types of mistakes earlier, in a compiler warning, it might save a lengthy validation procedure to catch the error (if it gets caught at all). > > Just thought folks might be interested in this gcc bug -- I certainly wasn't aware of it. > > Andy > > -----Original Message----- > From: Devel devel-bounces(a)sel4.systems On Behalf Of Matthew.Brecknell(a)data61.csiro.au > Sent: Thursday, November 8, 2018 7:22 PM > To: devel(a)sel4.systems > Subject: Re: [seL4] seL4 10.1.0 and camkes-3.6.0 > > Hi, > > Now that the fix for this issue has made it through our integration pipeline, I can explain what happened, since some of you might be interested. The fix is here: > > https://github.com/seL4/seL4/commit/d12bb374ab47d2b13f438969d2eb5dde1021af84 > > At line 56, the target variable was originally declared uninitialised. > If the loop at lines 57 to 64 executes at least once, then the variable is initialised at line 58. But if the loop does not execute, then the variable would remain uninitialised when it is used at line 65. This would be the case if infer_cpu_gic_id was ever called with nirqs <= 0. > This is not a problem in the released kernel, becuase infer_cpu_gic_id is only ever called once in dist_init, with 32 <= nirqs <= 1024. > > However, the binary translation validation test that failed does not do the inter-procedural analysis that would be necessary to realise this. > When looking at infer_cpu_gic_id, the analysis allows nirqs to take any value. It considers that the loop might not execute, and therefore target might be uninitialised when it is used at line 65. The dataflow model that is produced by the analysis cannot model such undefined behaviour, and so the test fails. With the fix, the variable is never uninitialised, so the analysis does not run into this problem. > > In summary, the fix you see here keeps our proofs happy, but it does not increase the safety of the kernel. This function, as it is actually used, was already safe. > > In terms of our development process, this kind of failure in the binary translation validation is quite rare and difficult to predict. And since our proofs take quite a long time to run, we don't always insist that our kernel developers run the proofs for changes in boot code, which is currently unverified except for binary translation validation. We accept that these failures will occasionally happen, and we deal with them when they do. The functions dist_init and infer_cpu_gic_id are boot-only code, so this was one of those rare failures. > > Of course, we should insist on running all the tests for versions we intend to formally release, and we will for future releases. > > Best regards, > Matt > > From: Brecknell, Matthew (Data61, Kensington NSW) > Sent: Thursday, 8 November 2018 11:25 AM > To: devel(a)sel4.systems > Cc: Mcleod, Kent (Data61, Kensington NSW) > Subject: Re: seL4 10.1.0 and camkes-3.6.0 > > Hi, > > Due to an oversight on my part, seL4 10.1.0 was released without passing the full verification test suite. > > We have no reason to believe that there is any problem in the verified parts of this seL4 version. > > The test that failed is part of the binary translation validation, which produces a dataflow graph from the Isabelle/HOL model of the C code, and then attempts to automatically prove a refinement relation between the C and that dataflow graph. The failure occurred in boot code, which in any case is currently not verified. The failure does not mean that there is any problem with the C code. Most likely, it just means that some new code uses some C idiom which is currently not handled by the automatic translation process. > > All other components of the verification test suite pass, including security proofs and functional correctness proofs for the Isabelle/HOL model of the C code. > > Nevertheless, we intend to rectify this failure as soon as possible, and we'll make further announcements when we understand what happened. > > I want to reiterate that this was entirely my fault, and was not at all Kent's fault. > > Best regards, > Matt > > From: Devel devel-bounces(a)sel4.systems on behalf of Kent.Mcleod(a)data61.csiro.au Kent.Mcleod(a)data61.csiro.au > Sent: Thursday, 8 November 2018 8:44 AM > To: devel(a)sel4.systems > Subject: [seL4] seL4 10.1.0 and camkes-3.6.0 > > See an online copy of the release notes at: > https://docs.sel4.systems/sel4_release/seL4_10.1.0 > https://docs.sel4.systems/camkes_release/Camkes_3.6.0 > > 10.1.0 2018-11-07: SOURCE COMPATIBLE > > Changes > > -------- > > - structures in the boot info are not declared 'packed' > - these were previously packed (in the GCC attribute sense) > - some field lengths are tweaked to avoid padding > - this is a source-compatible change > - ARM platforms can now set the trigger of an IRQ Handler capability > - seL4_IRQControl_GetTrigger allows users to obtain an IRQ Handler capability > and set the trigger (edge or level) in the interrupt controller. > > - Initial support for NVIDIA Jetson TX2 (ARMv8a, Cortex A57) > - AARCH64 support added for raspberry pi 3 platform. > - Code generation now use jinja2 instead of tempita. > - AARCH32 HYP support added for running multiple ARM VMs > - AARCH32 HYP VCPU registers updated. > - A new invocation for setting TLSBase on all platforms. > - seL4_TCB_SetTLSBase > - Kbuild/Kconfig/Makefile build system removed. > > camkes-3.6.0 2018-11-07 > Using seL4 version 10.1.0 > > Changes > > -------- > > - AARCH64 is now supported. > - CakeML components are now supported. > - Added `query` type to Camkes ADL to allow for querying plugins for component configuration values. > - Components can now make dtb queries to parse device information from dts files. > - Component definitions for serial and timer added on exynos5422, exynos5410, pc99. > - Preliminary support for Isabelle verification of generated capDL. > - See cdl-refine-tests/README for more information > - Simplify and refactor the alignment and section linking policy for generated Camkes binaries. > - Dataports are now required to declare their size in the ADL. > - Templates now use seL4_IRQHandler instead of seL4_IRQControl, which is consistent with the seL4 API. > - This change is BREAKING. > - Remove Kbuild based build system. > - Remove caches that optimised the Kbuild build system, which are not required with the new Cmake build system. > - Added virtqueue infrastructure to libsel4camkes, which allows virtio style queues between components. > > > Upgrade Notes > > -------------- > > - Any dataport definitions that did not specify a size must be updated to use a size. > - Any template that used seL4_IRQControl must be updated to use seL4_IRQHandler. > - Projects must now use the new Cmake based build system. > > Devel mailing list > Devel(a)sel4.systems > https://sel4.systems/lists/listinfo/devel > > Devel mailing list > Devel(a)sel4.systems > https://sel4.systems/lists/listinfo/devel > > -------------------------------------------------------------------------------- > > Subject: Digest Footer > > Devel mailing list > Devel(a)sel4.systems > https://sel4.systems/lists/listinfo/devel > > > --------------------------------------------------------------------------------- > > End of Devel Digest, Vol 54, Issue 12

2 1

seL4 10.1.0 and camkes-3.6.0
by Kent.Mcleod＠data61.csiro.au 14 Nov '18

14 Nov '18

See an online copy of the release notes at: <https://docs.sel4.systems/sel4_release/seL4_10.1.0> <https://docs.sel4.systems/camkes_release/Camkes_3.6.0> 10.1.0 2018-11-07: SOURCE COMPATIBLE ## Changes * structures in the boot info are not declared 'packed' - these were previously packed (in the GCC attribute sense) - some field lengths are tweaked to avoid padding - this is a source-compatible change * ARM platforms can now set the trigger of an IRQ Handler capability - seL4_IRQControl_GetTrigger allows users to obtain an IRQ Handler capability and set the trigger (edge or level) in the interrupt controller. * Initial support for NVIDIA Jetson TX2 (ARMv8a, Cortex A57) * AARCH64 support added for raspberry pi 3 platform. * Code generation now use jinja2 instead of tempita. * AARCH32 HYP support added for running multiple ARM VMs * AARCH32 HYP VCPU registers updated. * A new invocation for setting TLSBase on all platforms. - seL4_TCB_SetTLSBase * Kbuild/Kconfig/Makefile build system removed. ---- camkes-3.6.0 2018-11-07 Using seL4 version 10.1.0 ## Changes * AARCH64 is now supported. * CakeML components are now supported. * Added `query` type to Camkes ADL to allow for querying plugins for component configuration values. * Components can now make dtb queries to parse device information from dts files. * Component definitions for serial and timer added on exynos5422, exynos5410, pc99. * Preliminary support for Isabelle verification of generated capDL. - See cdl-refine-tests/README for more information * Simplify and refactor the alignment and section linking policy for generated Camkes binaries. * Dataports are now required to declare their size in the ADL. * Templates now use seL4_IRQHandler instead of seL4_IRQControl, which is consistent with the seL4 API. - This change is BREAKING. * Remove Kbuild based build system. * Remove caches that optimised the Kbuild build system, which are not required with the new Cmake build system. * Added virtqueue infrastructure to libsel4camkes, which allows virtio style queues between components. ## Upgrade Notes * Any dataport definitions that did not specify a size must be updated to use a size. * Any template that used seL4_IRQControl must be updated to use seL4_IRQHandler. * Projects must now use the new Cmake based build system.

4 4

Data61 Seeking Research Scientist
by Gerwin.Klein＠data61.csiro.au 14 Nov '18

14 Nov '18

Data61 Seeking Research Scientist ================================= We are looking for a full-time research scientist in formal verification to join us, the Trustworthy Systems group, at Data61, CSIRO. Our highly international team is located on the UNSW campus, close to the beautiful beaches of sunny Sydney, Australia, one of the world's most liveable cities. Our vision is a world in which computer users can choose all three: correct, secure, and fast. We believe that most current approaches to building systems are fundamentally flawed. We aim to demonstrate a better way. Our approach is rooted in foundational, formal verification using theorem provers (e.g., Isabelle, HOL4), and high-performance system design. If you find this vision appealing, and have ideas about how to pursue it, we want to hear from you. Our team brings together a unique combination of expertise in systems, security, formal verification, and programming languages. We are the creators of seL4, the world's first operating system microkernel with a machine-checked proof (in Isabelle/HOL). seL4 boasts both extreme performance and foundational binary-level correctness and security proofs. We are also involved in CakeML, the most realistic verified compiler for a functional programming language, and a promising approach to scaling full verification up to applications code. We are building on these successes in various directions, including concurrency (formal reasoning and implementation), timing (real-time guarantees and timing channels), and whole-system verification using component systems (e.g., CAmKES) and code+proof co-generation. We publish in top conferences, and are involved in multiple international research collaborations. You will have the opportunity to teach at UNSW should you wish to take it. We have a flexible, friendly, and intellectually stimulating work environment. We value diversity in all forms and welcome applications from people of all ages, including people with disabilities, and those who identify as LGBTIQ. See https://ts.data61.csiro.au/diversity/ for more information. The salary range for this position (plus superannuation) is - Research Scientist: 97k-105k - Senior Research Scientist: 111k-130k depending on experience and qualifications. Apply online here: https://jobs.csiro.au/job/Sydney%2C-NSW-Research-ScientistSenior-Research-S… Your application should include a cover letter, CV, short research statement, and contact information for two references. This round of applications closes on 15 January 2019. For any questions on this position, please contact June.Andronick(a)data61.csiro.au

1 0

Data61 Seeking Proof Engineers
by Gerwin.Klein＠data61.csiro.au 14 Nov '18

14 Nov '18

Data61 Seeking Proof Engineers ============================== We are are hiring again! If only there were a place where I could prove theorems for money, change the world, and have fun while doing it... Sounds too good to exist? In the Trustworthy Systems team at Data61 that's what we do for a living. We are the creators of seL4, the world's first fully formally verified operating system kernel with extreme performance and strong security & correctness proofs. Our highly international team is located on the UNSW campus, close to the beautiful beaches of sunny Sydney, Australia, one of the world's most liveable cities. We are looking for multiple motivated proof engineers who want to join our team in Sydney, move things forward, and have global impact. You would - work on industrial-scale formal proofs in Isabelle/HOL - develop formally verified infrastructure for building secure systems on top of seL4 - contribute to improved proof automation and reasoning techniques - apply formal proof to real-world systems and tools To apply for this position, you should possess a significant subset of the following skills. - functional programming in a language like Haskell, ML, or OCaml - first-order or higher-order formal logic - basic experience in C - ability and desire to quickly learn new techniques - undergraduate degree in Computer Science, Mathematics, or similar - ability and desire to work in a larger team We are hiring at two levels, so if you are more qualified or experienced than the above would suggest, you can come in as a senior proof engineer. If you additionally have experience - in software verification with an interactive theorem prover such as Isabelle/HOL, HOL4, or Coq, and/or - with operating systems and microkernels you should definitely apply! If you have the right skills and background, we can provide training on the job. Continual learning is a central component of everything we do. You will work with a unique world-leading combination of OS and formal methods experts, students at undergraduate and PhD level, engineers, and researchers from 5 continents, speaking over 15 languages. Trustworthy Systems is a fun, creative, and welcoming workplace with flexible hours & work arrangements. We value diversity in all forms and welcome applications from people of all ages, including people with disabilities, and those who identify as LGBTIQ. See https://ts.data61.csiro.au/diversity/ for more information. Salary ranges, in AUD (plus superannuation): - Junior Proof Engineer: 73k-93k - Senior Proof Engineer: 97k-105k depending on experience and qualifications. Apply online at the following link for the Proof Engineer positions: - https://jobs.csiro.au/job/Sydney%2C-NSW-Proof-Engineer/518443000/ - https://jobs.csiro.au/job/Sydney%2C-NSW-DATA-61/518441000/ Your application should include a cover letter, CV, undergraduate transcript (if applicable), and contact information for two references. This round of applications closes on 17 December 2018. For any questions on these positions, please contact Rafal.Kolanski(a)data61.csiro.au or June.Andronick(a)data61.csiro.au The seL4 code and proof are open source. Check them out at https://seL4.systems More information about Data61's Trustworthy Systems team at https://ts.data61.csiro.au There are additional proof engineering positions available on the Cogent project. Cogent is a language we designed to ease the verification of systems components around seL4. For expressions of interest, see contact details on https://ts.data61.csiro.au/projects/TS/cogent.pml Looking to do a PhD? Data61 and UNSW (https://www.unsw.edu.au/) offer scholarships! See https://ts.data61.csiro.au/students/research.pml for details.

1 0

Scheduling of vCPUs on x86
by Alexander Boettcher 10 Nov '18

10 Nov '18

Hello, the time spend by a vCPU TCB (tcbTimeSlice) seems to be not accounted/updated by the seL4 kernel on a timer ticks, which leads to starvation of other TCBs running on the same or lower priority level. In one of our test setups, if once a vCPU runs and doesn't give up its timeslice willful (e.g. guest goes in while loop and thereby not causing a VM exit to be handled by the VMM), all other TCBs (normal threads and vCPUs) on the same timeslice are not considered to be scheduled again, since tcbTimeSlice of the vCPU stays full forever. Following patch seems to fix the issue. Can you please have a look and verify that it is correct ? Or should it be solved on another place in the kernel differently. Just out of curiosity, why is a separate thread state in the scheduler for x86 (CONFIG_VFX) required that is not needed for scheduling of a vCPU on ARM ? I didn't expect the scheduler thread states to be different between hardware architectures in seL4. Cheers, -- Alexander Boettcher Genode Labs https://www.genode-labs.com - https://www.genode.org Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

5 8