https://trustworthy.systems
seL4 R&D: What’s Next?
Gernot Heiser | [email protected] | @GernotHeiser• seL4 Summit, DC, Sep’19
10yo, Still the Best, Still Getting Better!
seL4 Summit | DC | Sep'192 |
• First OS kernel with proof of functional correctness• still the only one that’s not a toy
• First protected-mode RTOS with complete & soundworst-case execution-time analysis
• still the only one
• First OS with proof of security enforcement (integrity and confidentiality) of the OS binary code
• still the only one that’s not a toy
• First OS with time capabilities suitable for hard and mixed-criticality real time
• still the only one that’s real-world capable
• Still world’s fastest microkernel!
10 Years Old – What’s Next?• Quick background: licensing
• Quick background: capabilities
• D: Principled temporal reasoning for mixed-criticality systems (MCS)
• R: Time protection: Principled prevention of timing channels
• R: Cogent – high assurance beyond the kernel
• R&D: Verification update
• Announcement: Taking the community/ecosystem to the next level
Background: Licensing
5 Years Open-Source: Licensing
seL4 Summit | DC | Sep'195 |
Provided by Trustworthy Systems (TS@Data61)
GPL v2
Kernel source
GPL v2
Kernel proofs
System services:libs, drivers, file systems,
NW stacks, tools, …
BSD BSD
Related proof artefacts
Your code (applications)
any…
A Microkernel is not an OS
seL4 Summit | DC | Sep'196 |
Processor
DeviceDriverDevice
DriverDeviceDriver
NWStack
DeviceDriverDevice
DriverFileSystem
ProcessMgmt
MemoryMgmt
AppAppApp
VM
Linux
AppAppApp
Device drivers, file systems, crypto, power management, virtual-machine monitor are all user-mode processes
VMM
Microkernel = context-switching engineMicrokernel
seL4 vs Linux Licensing
seL4 Summit | DC | Sep'197 |
GPL v2
TS kernel source
GPL v2
kernel.org source• core kernel• device drivers• file systems• NW stacks• …
TS system services:libs, drivers, file systems,
NW stacks, tools, …
BSD
Your code (applications)
any…
GPL v2
Platform port:• timer• serial• HW init GPL v2
Platform port:• device drivers• HW init
Your system services
any…GPL v2
Your system services
Your code (applications)
any…
Valuable IPValuable IP
Boiler plate
Boiler plate
Background: Capabilities
Core Mechanism: Capability
seL4 Summit | DC | Sep'199 |
Obj referenceAccess rights
Capability = Access Token:Prima-facie evidence of privilege
Eg. read, write, send, execute…
Capabilities provide:• Fine-grained access
control• Reasoning about
information flow
Eg. thread, address spaceObject
Controlled Communication
seL4 Summit | DC | Sep'1910 |
VM1
Guest OS
Guest apps
Native untrusted
Nativetrusted
Channel
No communicationunless explicitly authorised!
ChannelChannel
VM2
Guest OS
Guest apps
Development:SupportingMixed-Criticality Systems (MCS)
MCS Challenge: Preemption
seL4 Summit | DC | Sep'1912 |
Runs every 100 msfor few millisecods
Runs frequently but for short time (order of µs)
Control loopSensor
readingsNW driver
NWinterrupts
NW driver must preempt control loop• … to avoid packet loss• Driver must run at high prio• Driver must be trusted not to monopolise CPU
CriticalLess
critical
MCS Challenge: Sharing
seL4 Summit | DC | Sep'1913 |
CriticalLess
critical
Vehicle Control
NavigationSharedData
Vehicle control must see consistent state
Updates
Sharing Through Delegation
seL4 Summit | DC | Sep'1914 |
ControlP1 Server
PSNavigationP2
Single-threaded “resource server”,guarantees atomicity
Communicationendpoint (port)
Who pays for server time?
Idea: Capabilities for Time
seL4 Summit | DC | Sep'1915 |
“Traditional” seL4: access to all spatialresources authorised by a cap• memory• communication endpoints• threads• interrupts…
New MCS seL4: capabilities also authorise access to CPU time
Scheduling Contexts: Time Capabilities
seL4 Summit | DC | Sep'1916 |
Classical thread attributes• Priority• Time slice
New thread attributes• Priority• Scheduling context capability
Not runnable if null
Not runnable if null
Scheduling context object• T: period• C: budget (≤ T)
Limits CPU access!
C = 2T = 3
C = 250T = 1000
Capability for CPU time
MCS with Scheduling Contexts
seL4 Summit | DC | Sep'1917 |
Runs every 100 msfor few millisecods
Runs frequently but for short time (order of µs)
Control loop
P = lowSensorreadings
NW driver
P = high
NWinterrupts
C = 2T = 3Utilisation = 67%
C = 25,000T = 100,000Utilisation = 25%
Client1P1
Shared Server as “Passive” Server
seL4 Summit | DC | Sep'1918 |
ServerPS
RunningRunning
Server runs on client’s scheduling
context
Client is charged for
server’s time
Client2P2
PS = max(P1,P2)• Implements immediate priority ceiling protocol (IPCP)• Efficient real-time locking protocol
Handling Budget Overrun• Timeout exception as policy-free mechanism• Possible policies (implemented at user level):
• ignore – block thread until budget replenished• provide emergency budget to shared server• abandon request and roll-back server• implement priority inheritance (yuck!)
Server
Timeout Handler
MCS Kernel Status• Model published in EuroSys’18: “Scheduling-context capabilities: a
principled, light-weight OS mechanism for managing time” [Lyons et al]• Code recently merged into mainline• Verification in progress – to be completed this year• MCS model is forward-compatible with traditional seL4• Traditional model to be deprecated once MCS verification finished
MCS model cleans up many other things⇒ do not use traditional model for any new work!
First capability system for hard
real-time!
Research:Time Protection
Threats
seL4 Summit | DC | Sep'1922 |
Speculation
Microarchitectural Timing Channel
An “unknown unknown” until
recently
A “known unknown”
for decades
Cause: Competition for HW Resources
seL4 Summit | DC | Sep'1923 |
High Low
Affect execution speed
Shared hardware
• Inter-process interference• Competing access to micro-
architectural features • Hidden by the HW-SW contract!
Sharing 1: Stateless InterconnectH/W is bandwidth-limited• Interference during concurrent
access• Generally reveals no data or
addresses• Must encode info into access
patterns• Only usable as covert channel, not
side channel
High Low
Sharedinterconnect
Memory No effective defencewith present hardware!
seL4 Summit | DC | Sep'1924 |
Sharing 2: Stateful HardwareHW is capacity-limited• Interference during• concurrent access• time-shared access
• Collisions reveal addresses• Usable as side channel
Cache
High Low
Any state-holding microarchitectural feature:• cache, branch predictor, pre-fetcher state machine
Solvable problem –focus of this work
seL4 Summit | DC | Sep'1925 |
Systematic Defence: Time ProtectionHigh Low
A collection of OS mechanisms which collectively prevent interference between security domains that make execution in one domain dependent on the activities of another.
[Ge et al. EuroSys’19]
seL4 Summit | DC | Sep'1926 |
Time Protection: Prevent InterferenceHigh Low
Affect execution speed
Shared hardware
Interference results from sharing⇒ Partition hardware:•spatially• temporally (time shared)
seL4 Summit | DC | Sep'1927 |
Time Protection: Partition HardwareHigh Low
Cache Flush
Temporally partition
Cannot spatially partition on-core caches (L1, TLB, branch predictor, pre-fetchers)• virtually-indexed• OS cannot control
Cache
High Low
High Low
Cache
Spatially partition
Flushing useless for concurrent access• HW threads• cores
Needboth!Needboth!
seL4 Summit | DC | Sep'1928 |
Spatially Partition: Cache Colouring
seL4 Summit | DC | Sep'1929 |
Cache
RAM
• Partitions get frames of disjoint colours• seL4: userland supplies kernel memory⇒ colouring userland colours dynamic kernel memory
• Per-partition kernel image to colour kernel[Ge et al. EuroSys’19]
High Low
TCB PT PTTCB
Temporal Partitioning: Flush on Switch
seL4 Summit | DC | Sep'19
1. T0 = current_time()2. Switch user context3. Flush on-core state4. Touch all shared data needed for return5. while (T0+WCET < current_time()) ;6. Reprogram timer7. return
Latency dependson prior execution!
Time padding to Remove
dependency
Ensure deterministic
execution
Must remove any history dependence!
30 |
Challenge: Broken Hardware• Systematic study of COTS hardware (Intel and Arm) [Ge et al, APSys’18]:
• contemporary processors hold state that cannot be reset• need a new hardware-software contract to enable real security
seL4 Summit | DC | Sep'1931 |
Small channel!
RISC-V will provide suitable
contract
Status• Published analysis of hardware mechanisms (APSys’18) – Best Paper• Published time protection design and analysis (EuroSys’19) – Best Paper
• demonstrated effectiveness within limits set by hardware flaws (Arm, x86)
• Published planned approach to verification (HotOS’19)• Working on:
• Evaluation on conforming RISC-V hardware• Integrating time-protection mechanisms with clean seL4 model• Proving timing-channel absence (on conforming hardware)
seL4 Summit | DC | Sep'1932 |
Research:High AssuranceBeyond the Kernel
Verification Cost
seL4 Summit | DC | Sep'1934 |
C Imple-mentation
Proo
fExecutable
Model
AbstractModel
Proo
f
120,000 LoP, 8 py
50,000 LoP, 3 py
Life-Cycle Cost in Context
seL4 Summit | DC | Sep'1935 |
L4Pistachio
$100
seL4$400
Green HillsIntegrity$1000
Ass
uran
ce
Cost ($/SLOC)1000750500250100
Slow!
Fast!Fast!
?Revolution!
Beyond the Kernel
seL4 Summit | DC | Sep'1936 |
Criticalcontrol
Uncritical/untrusted
Linux
AppsAppsApps
Devicedriver
NWstack
10 kLOC11 py
100 kLOC?
5 kLOC?
1 kLOC?
File system
10 kLOC?
Cogent: Code & Proof Co-Generation
seL4 Summit | DC | Sep'1937 |
• Restricted, purely functional systems language
• Type- and memory safe, not managed
• Turing incomplete• File system case-studies:
BilbyFs, ext2, F2FS, VFAT
[O’Connor et al, ICFP’16; Amani et al, ASPLOS’16]
Abstract SpecIsabelle/HOL
Proo
fPr
oof
ADTs (C)C
Cogent
Proo
f
Auto-matic
Manual,one-off
Manual,equational
Aim: Reduce cost of verified systems code
⚭
Dependable And Affordable?
seL4 Summit | DC | Sep'1938 |
Fully automated
Work in progress:• Language expressiveness• Reduce boiler-plate code• Network stacks • Device drivers
Dependability-cost tradeoff:• Reduced faults through safe language• Property-based testing (QuickCheck)• Model checking• Full functional correctness proof
???
Abstract Spec
Proo
f?Pr
oof
C
Cogent
Specreuse!Spec
reuse!
Application to Autonomous Cars
seL4 Summit | DC | Sep'1939 |
Arm v8 core
Microkernel
Arm v8 core Arm v8 core Arm v8 core
CANdriver
Sensordriver
Cameradriver
Inference engine
Virtual Machine
SMP Linux
Logging
SensorFusion
Comms
ML TrustedRedundancy
Cogent
R&D:Verification
AbstractModel
Proof
C Imple-mentation
Proof
Confidentiality Availability
Binary code
Proo
fPr
oof
Proo
f
Functional correctness: C code only behaves as specified by model
Security properties:Model enforces isolation
Translation validation:Binary retains
C-code semantics Limitations (work in progress):• Kernel initialisation not yet verified• MMU & caches modelled abstractly• Multicore kernel not yet verified• Timing channels not ruled out
Sound worst-case execution time (WCET) bound
Verification
seL4 Summit | DC | Sep'1941 |
Integrity
Feature Model to C
C to binary
Security VM support
MCS Multi-core
Arm 32 done done done done Q419 in progr.x64 done no plans no plans no plans easy? ???RISC-V 64 Q4’19 Q3’19 TBD unfunded Q4’19 unfundedArm 64 unfunded in progr. unfunded unfunded unfunded unfunded
Verification Matrix
seL4 Summit | DC | Sep'1942 |
Feature Model to C
C to binary
Security VM support
MCS Multi-core
Arm 32 done done done done Q419 in progr.x64 done no plans no plans no plans easy? ???RISC-V 64 Q4’19 Q4’19 TBD unfunded Q4’19 unfunded
Feature Model to C
C to binary
Security VM support
MCS Multi-core
Arm 32 done done done done Q419 in progr.x64 done no plans no plans no plans easy? ???
Feature Model to C
C to binary
Security VM support
MCS
Arm 32 done done done done Q419x64 done no plans no plans no plans easy?
Feature Model to C
C to binary
Security VM support
Arm 32 done done done donex64 done no plans no plans no plans
Feature Model to C
C to binary
Security
Arm 32 done done donex64 done no plans no plans
Feature Model to C
C to binary
Security
Arm 32 done done done
• Security: CIA enforcement proofs• MCS: Mixed-criticality support with time capabilities• VM support: verified use of hardware virtualisation support
Community/Ecosystem
We Are Creating the seL4 Foundation!Aim: • Neutral entity for coordinating & enhancing seL4 ecosystem• Improve (organisational and individual) community participation• Coordinate with CoE (as a provider of defence-grade distributions)• Develop / standardise seL4 system (kernel & proofs, libraries, services, tools)• Protect seL4 brand• Provide platform for pooling funds for critical “big-ticket” items (verification)• Looking for (institutional) Founding Members
seL4 Summit | DC | Sep'1944 |
Any Problems With Using/Deploying?
seL4 Summit | DC | Sep'1945 |
Talk To Us!!!!