MIDORIThe Windows Killer!!

by-Sagar R. Yeole

Under the guidance of- Prof. T. A. Chavan

Overview

1. Introduction to Midori O/S2. Design Methodologies3. Micro Kernel4. Software Isolated Processes5. Communication Channels6. Manifest-Based Programs7. Compile-Time Reflection8. Heterogeneous Multiprocessing9. Programming Languages Used10. Performance11. Conclusion

Whatis

Midori ?

“ What would a software platform look like if it was designed from scratch, with the primary goal of improved

dependability and trustworthiness? “

What is the need for a new Operating System?

Midori Motivation

• Current operating systems have modules over 40 years old– Is this really modern?

• Why has it not been updated?– Backwards compatibility is a burden

• So what does change?– Software has evolved (Java, C#)– Hardware drives most changes

Midori Motivation• Dependability :

“The notion of dependability, defined as the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers, enables these various concerns to be subsumed within a single conceptual framework. Dependability thus includes, as special cases, suchattributes as reliability, availability, safety and security.”

• Create dependability with protection and isolation

• Move error detection closer to design time

Design Methodology

• Written in Sing#(strongly typed “safe” language)• Microkernel Architecture

1. Software Isolated Processes (SIPs)2. Contract Based Channels3. Metadata Infrastructure

Micro kernel

Factors Monolithic kernel Micro kernelSize Huge Small

IPC Signals/Sockets Message queues

Security System-wide halt Local process hale

Correctness Hard to ensure Easier to ensure

I/O Communication Fully integration Message-per-IRQ

Design Overview

1. Software Isolated Processes (SIPs)2. Contract Based Channels3. Metadata Infrastructure

Software Isolated Processes(SIP)

• Shared address space for everything

• Everything is a isolated process

• Closed object / code spaces.

• No dynamic code execution

Software Isolated Processes(SIP)

• Protection and safety not from Memory Management HW– Language safety and verification tools in SW

• Execute independently- each has own:– Layout– Runtime systems– Garbage collectors

• Communication between SIPs highly regulated– Communicate through bidirectional, highly typed channels– Both ends of communication verified through OS– Rely on specific communications protocol

Address Space

Multiple Address Space(current systems)

Single Address Space(singularity)

Requires context switch for IPC-Processor state must be saved and restored-TLB must be flushed Enormous penalty for context switch

Efficient IPC through Exchange Heap

Loses memory hardware basedprotection mechanisms

• Partitioned into: Kernel Object space Object spaces for each SIP Exchange heap

•OS only needs one:Error Recovery ModelCommunications MechanismSecurity ArchitectureProgramming Model

SIP Cost

• Inexpensive to create– Communication has low overhead– Cost comparison:

SystemCost(in CPU Cycles)

APICall

ThreadYield

MessagePing/Pong

CreateProcess

Midori 91 346 803 352,873

Free BSD 878 911 13,304 1,032,254

Linux 437 906 5,797 719,447

Windows 627 753 6,344 5,375,735

Design Overview

1. Software Isolated Processes (SIPs)2. Contract Based Channels3. Metadata Infrastructure

Channels• Only way for SIPs to communicate

– Needs to be fast (unlike current systems)

• Each channel is– bi-directional– defined by exactly two endpoints

• Each endpoint– Has its own queue– Belongs to exactly one thread at a time

• Endpoints and values in Exchange Heap• Message synchronization:

Sends ReceivesAsynchronous Synchronous

block until specific message arrives

Exchange Heap

Design Overview

1. Software Isolated Processes (SIPs)2. Contract Based Channels3. Metadata Infrastructure

Metadata

• Describes a program’s– Resources– Capabilities– Dependencies

• Defined at Design-Time– Specified with inline code

• Prevents conflicts

• Facilitate static verification of run-time properties

Manifest

• Single XML Sheet with Program Metadata

• Generated at compile time

• Defines Installation Procedure

• No code can run without a manifest– Kernel, device drivers and user applications all have Manifests

• To start execution, invoke manifest (not executable)

Installation

1. Load Manifest

2. Check for Conflicts

3. Verify Dependencies (Versioned)

4. Instantiate Compile-Time Reflection procedures

5. Replace ABIs Interface assemblies with process-side implementation assemblies

ABI

• Application Binary Interface– API- source code compatibility; ABI- OS compatibility

• Follows principle of least privilege– SIPs do not have much default ability– Gain access to higher-level systems through channels

• Kernel ABI Strongly versioned– Good for backwards compatibility

• ABI calls more expensive than function calls

ABI

• Privileged Code

HW Protection (Other)Run program in kernel mode

SW Protection (Midori)Privileged instructions can be in trusted functions in SIP

ABI functions can be in-lined into SIP code at installation

ABI

Features Functions

Channels 22

Child Processes 21

Configuration 25

Debugging & Diagnostics 31

Exchange Heap 8

Hardware Access 16

Linked Stacks 6

Paged Memory 17

Security Principals 3

Threads & Synchronization 43

Total 192

• ABI functions by feature

Compile-Time Reflection

• Reflection:The ability of a program to modify its behavior or is structure.

• Run-Time Reflection– Basis of Java VM and CLR– Explicitly Prohibited in Singularity

• Compile-Time Reflection– High Level Transform Constructs are created at compile time– Act like templates– Placeholders are filled by a generator later– Can be statically verified at compile time

Heterogeneous Multiprocessing

• Dynamic Specialization:Processors are designated to run only OS code or Application code

– Improved Branch Prediction– Improved Cache Locality– Conducted by Chakraborty et al.

• Singularity Lends itself to this specialization through theMicrokernel implementation.

– Servicing applications can be designated to specific cores easierthan in a Monolithic implementation

Programming Languages Used

• Sing #– 90% of the kernel is written in type safe Sing#– A significant code is written in unsafe sing

• Out of which 48% is Garbage Collector• Remaining is Memory Management & IO Subsystems

• C++– 6% of the code is written covering kernel debugger & low level system

initialization code

• Assembly Language– Small Pockets of Assembly Language is used

Disk Performance: Read

Disk Performance: Write

Inter Process Communication Cost

MessageSize(bytes)

CPU CyclesMidori Linux Windows

4 933 5,544 6,641

16 928 5,379 6,600

64 942 5,549 6,999

256 929 5,519 7,353

1,024 926 5,971 10,303

4,096 919 8,032 17,875

16,384 928 19,167 47,149

65,536 920 87,941 187,439

Why is Midori termed as“The Windows Killer”?

Conclusion

Thank You…

Any Questions…

??

? ?

?

?