seL4 R&D: What’s Next?...Binary code f f f Functional correctness: C code only behaves as...

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


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


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


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


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


any…

Valuable IPValuable IP

Boiler plate

Boiler plate

Background: Capabilities

Core Mechanism: Capability


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


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


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


CriticalLess

critical

Vehicle Control

NavigationSharedData

Vehicle control must see consistent state

Updates

Sharing Through Delegation


ControlP1 Server

PSNavigationP2

Single-threaded “resource server”,guarantees atomicity

Communicationendpoint (port)

Who pays for server time?

Idea: Capabilities for Time


“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


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


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


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


Speculation

Microarchitectural Timing Channel

An “unknown unknown” until

recently

A “known unknown”

for decades

Cause: Competition for HW Resources


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!


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


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]


Time Protection: Prevent InterferenceHigh Low

Affect execution speed

Shared hardware

Interference results from sharing⇒ Partition hardware:•spatially• temporally (time shared)


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!


Spatially Partition: Cache Colouring


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


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)


Research:High AssuranceBeyond the Kernel

Verification Cost


C Imple-mentation

Proo

fExecutable

Model

AbstractModel

Proo

f

120,000 LoP, 8 py

50,000 LoP, 3 py

Life-Cycle Cost in Context


L4Pistachio

$100

seL4$400

Green HillsIntegrity$1000

Ass

uran

ce

Cost ($/SLOC)1000750500250100

Slow!

Fast!Fast!

?Revolution!

Beyond the Kernel


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


• 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?


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


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


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


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


Any Problems With Using/Deploying?


Talk To Us!!!!

https://sel4.systems

Gernot Heiser | [email protected] | @GernotHeiser

THANK YOU

seL4 R&D: What’s Next?...Binary code f f f Functional correctness: C code only behaves as...

Documents

Transcript of seL4 R&D: What’s Next?...Binary code f f f Functional correctness: C code only behaves as...