## Security Kernels
- Problem with Multics:
	- Slow, large and complex
	- Hard to achieve performance, generality and security
- Two trends:
	- UNIX (focus on generality and performance)
	- Security kernels (security, performance and verifiability)
- Definition:
	- *A security kernel is defined as the hardware and software necessary to realize the reference monitor abstraction*
- Systems:
	- Secure Communications Processor (SCOMP)
	- KSOS/PSOS
	- SLAN
	- Secure Ada Target
- Core principles:
	- Implement *security policy* (define in MPS)
	- Define a verifiable *protection behavior of the system* (reference monitor)
	- Implementation must be faithful to the security goals
- Formal Verification
	- Became the main focus
	- Limits: 
		- Can't detect errors in specification
		- Can't detect incomplete coverage of the functionality in the specification

### MITRE
- MITRE Project, 1974
- First security kernel
- Manage system resources directly
- Less than 20 subroutines
- Less than 1 kLOC

### Secure Communications Processor (SCOMP)
- Honeywell, 1983
- Security kernel-based system
- Policy: Multics Multilevel Security

#### Architecture
- Scomp hardware mechanisms (by Honeywell)
- Trusted Computing Base:
	- Runs in rings 0,1,2
	- Scomp Trusted OS
		- Kernel (ring 0)
		- Trusted Software (ring 1)
	- Scomp Kernel Interface Package
		- Trusted functions (ring 2)
- Untrusted
	- Scomp Kernel Libraries (ring 3)
	- Applications

![](images/scomp.png)

#### Fundamentals
- Similarities to Multics
	- Access control via segments (memory + I/O)
	- Secrecy using Multilevel Security
	- Ring Brackets
- Differences to Multics
	- Access control/ring implemented in hardware
	- Formal verification
		- Enforcing the policy (*‌formal top-level specification*)
		- Trusted software outside the kernel is verified using a procedural specification
	- Separate kernel from system API (e.g., file access)
- Security kernel
	- Manages hardware descriptors (containing address and access rights)

#### Hardware
- Complete mediation is implemented in hardware
- Inspired by Multics
- Fundamental changes to Multics:
	- Only four protection rings
	- *Security protection module* (complete mediation)
- *Argument addressing mode*
	- Scenario: Lower-privileged process calls higher-privileged routine
	- Goal: Prevent confused deputy
	- Comparable to Multics' gatekeepers
	- Caller provides memory page with arguments 

![](images/scomphardware.png)
##### Security protection module (SPM)
- Mediate all memory and I/O accesses in the Scomp system
- Mediate on main system bus
	- Provides access to I/O and memory
	- SPM maps virtual device name to I/O descriptor
- Memory mediation
	- SPM has hardware cache
- I/O mediation
	- I/O operation requests a physical address from virtual name 
- SPM and Direct Memory Access
	- *DMA*: Access memory without CPU (required for performance reasons)
	- *Pre-mapped DMA*:
		- Driver accesses device/memory
		- SPM authenticates a DMA request once 
		- SPM caches request 
	- *Mapped I/O*:
		- Map devices (I/O descriptors) to addresses/registers
		- Device listens on system bus for address
		- Send address to device
		- Device can perform DMA directly
	- Result:
		- Kernel only constructs the I/O descriptor
		- Mediation performed by SPM
		- Drivers can be run outside the kernel
- AMD/Intel:
	- Adopted four rings but ignored hardware mediation
	- Problem: DMA bypasses CPU (security problem)
	- Added I/O MMUs (inspired by SPM)
	- I/O MMUs mediates I/O access

![](images/iomapping.png)
##### Drivers
- Scomp runs driver in user-space
- Workflow
	- Driver performs I/O operations
	- Kernel maps I/O to address
	- SPM uses pre-mapped DMA (SPM only authorizes first request)
	- User process (i.e., driver) can directly address device
- Advantage:
	- Performance (user process/driver directly communicates with device without the CPU)
	- Stability (drivers often cause kernel fault)

#### Operating System
- Security Kernel
	- Ring 0
	- Minimized (10 kLOC, Pascal)
	- Tasks:
		- Memory management
		- Process scheduling
		- Interrupt management
		- Auditing
		- Reference monitoring functions
	- Access Control:
		- Multilevel security (i.e., Bell-LaPadula)
		- Ring bracket policy
		- Discretionary policies
	- Ring transitions
		- 38 gates
		- Similar to modern syscalls (e.g., map segments)
		- Provide argument validation (compare to Multics gatekeepers)
- Trusted Software
	- Rings 1 + 2
	- Software trusted to not violate security goals (e.g., process loading)
	- Software trusted to maintain security policy correctly (e.g., authentication services)
	- 23 trusted functions (11 kLOC)
- Kernel Interface
	- Ring 2
	- Comparable to syscall interface
	- Trusted operations on user-level objects
	- Trusted not to violate MLS requirements

#### User Software
- Scomp Kernel Interface Package Library
- Ring 3 (untrusted)
- Compare to `libc`/POSIX API
- *Mail Guard*
	- Mail client ensuring MLS policy
	- Information not leaked to less secret subjects

#### Evaluation
- Complete Mediation
	- Mediate all security-sensitive operations: Hardware enforcement
	- Mediate on all objects: Hardware enforcement
	- Verification: Hardware verification
	- Problem: What about data inside the system?
- Tamperproof
	- Protect reference monitor: Protection rings
	- Protect TCB:
		- Protection rings and bracket model
		- Leads to integrity (No untrusted code runs in rings 0-2)
		- More complex system than Multics (*no more specification in book*)
- Verification
	- Correctness of TCB: Formal verification (using semi-automated methods)
	- Enforcement of security goals: mandatory MLS policy + discretionary bracket policy
- Result:
	- Verification by DoD's Trusted Computer System Evaluation Criteria (TCSEC)
	- A1 evaluation level (most secure evaluation level)

### Driver Isolation
- Problem:
	- Scomp in 1983 had complete mediation
	- Later technologies had incomplete mediation (did not use SPM)
	- Faulty drivers are major cause of OS crash
	- 2/3 of code base are *extensions*
	- 65 - 83 % of crashes in Windows XP are caused by drivers
	- Fixing drivers is infeasible (too rapid growth)
- Idea: 
	- Isolate drivers
	- Use I/O MMUs for mediation
	- Can be more effective
- Attacks malicious driver:
	- Wipe out kernel memory
	- Overwrite drivers (memory corruption)
- Design principle: Least Authority

#### Historical driver isolation
- Source: Herder et al., 2007, Chapter 4
- Use trusted kernel + MMU
- Driver gets own virtual address space
- MMU denies DMA
- Kernel copies data between memory segments
- Process must authorize DMA
	- Explicitly define address space and access rights
	- Pass to other party
- Approaches:
	- Use better programming language
	- Place driver in virtual machine

#### Memory Management Unit (MMU)
- Task: Map virtual to physical addresses (use page tables of process)
- Driver in virtual address space limits contexts it can access
- Problem:
	- Driver must access device
	- Device performs DMA
	- Device performs operations important for the OS
	- --> Using CPU is too slow
- IOMMU:
	- Used for DMA
	- Requires DMA-capable bus
	- Map device address/IO address to physical address

![](images/iommu.png)
#### Fault Isolation for Device Drivers
- Source: Herder et al. 2009. Fault Isolation for Device Drivers
- Focus: Isolating untrusted drivers that threaten OS dependability
- Assumptions
	- Requires IOMMU
	- Blocking of interrupt requests (IRQ): Multiple devices receive an IRQ, one blocks the IRQ due to the PCI standard
	- PCI sharing: Communication over PCI can't be isolated (only using PCI-E)
- Limitations
	- MINIX 3: 10-20 % overhead in macro benchmark
- Overview
	- Based on MINIX 3 (adheres to principle of least privilege/authority)
	- Driver runs as user-mode process
	- Each process has private (IO)MMU-protected address space
	- Policies on driver-basis
	- Reference monitor: Kernel + trusted OS
- **Does this implement a Reference Monitor???**

![](images/driver.png)
##### Enforce Least Authority
- Classify potentially dangerous driver operations:
	1. CPU usage
	2. Memory access
	3. Device I/O
	4. System services
- Restrict each class
- Isolation policy:

![](images/driver-policy.png)
###### CPU usage
- Privileged instructions
	- e.g., resetting page tables
	- Restriction: Put driver in user-space (no privileged operations)
- CPU time
	- e.g., infinite loop
	- Restriction:
		- Use scheduling
		- Send heart-beats and restart driver if not response
		- Use resource-reservation framework to protect real-time processes

###### Memory access
- Memory references
	- e.g., memory corruption
	- Restriction: Address space separation
		- Use hardware MMU
		- Driver gets personal address space
		- Driver accessing outside its space is killed
		- Problem: Page sharing is too coarse for exchanging small data structures 
- Copying/sharing
	- Feature to enable fine-grained sharing
	- Restriction: Run-time memory granting
		- Process can grant address spaces to other processes
		- Store these addresses in *grant table* (inside kernel (?))
		- Byte-level-granularity
		- Process specifies whether read/write is possible
		- Direct grant and indirect grants possible
		- Results in hierarchical structure
- DMA
	- Restriction:
		- Driver requests DMA from trusted IOMMU driver
		- DMA into driver's own address space is allowed

![](images/granting.png)
###### Device I/O
- Device access
	- e.g., wrong/unauthorized I/O access
	- Restriction: Per-driver I/O policy
		- Drivers have different requirements
		- Each driver gets policy with fine-grained access to the required resources
		- Driver manager reads policy from disk
		- Driver manager informs kernel and trusted OS servers
- Interrupt handling
	- e.g., hard to implement correctly
	- Restriction: User-level IRQ handling
		- Driver registers for interrupt notifications for a specific interrupt (IRQ) via `IRQCTL`
		- Kernel verifies the access rights with policy
		- Generic kernel-level handler disables interrupts, masks the IRQ, notifies the driver (`HWINT` message), re-enable interrupt controller
		- Driver can acknowledge the interrupt using `IRQCTL` to unmask IRQ line

###### System services
- Low-level IPC
	- e.g., unreliable/hostile sender
	- Restriction: Per-driver IPC policy
		- Generally, drivers are not allowed to use IPC
		- IPC can be specified in isolation policy
- OS services
	- e.g., request routing is privileged operation
	- Restriction: Per-driver call-policy
		- Isolation policy restrict access to kernel calls
		- Protect using POSIX

##### Evaluation
- Not really possible to evaluate
- MPS
	- Each driver has own policy
	- Protection state: Devices + Interfaces 
	- Labeling state: Driver-policy
	- Transition state: Not given
- Reference monitor
	- Complete mediation: Who does mediation?
		- IOMMU/MMU/Kernel (?)
	- Tamperproof: ?
	- Verification: Code+policy not provided