MIDORI

The Windows Killer!!

by-
Sagar R. Yeole

Under the guidance of-

Prof. T. A. Chavan
 Overview

• Introduction to Midori O/S

• Design Methodologies
• Micro Kernel
• Software Isolated Processes
• Communication Channels
• Manifest-Based Programs
• Compile-Time Reflection
• Heterogeneous Multiprocessing
• Programming Languages Used
• Performance
• Conclusion
What
is
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, such
attributes 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

11.Software Isolated Processes (SIPs)

12.Contract Based Channels
13.Metadata Infrastructure
 Micro kernel

Factors Monolithic kernel Micro kernel

Size 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

• Software Isolated Processes (SIPs)

• Contract Based Channels
• 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)
Requires context switch for IPC
-Processor state must be saved
and
restored
-TLB must be flushed
Enormous penalty for context
switch
• Partitioned into:
 Kernel Object space
 Object spaces for each SIP
 Exchange heap
Single Address Space
(singularity)
Efficient IPC through Exchange
Heap
Loses memory hardware based
protection mechanisms
•OS only needs one:
Error Recovery Model
Communications Mechanism
Security Architecture
Programming Model
 SIP Cost

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

Cost(in CPU Cycles)

System
API Thread Message Create
Call Yield Ping/Pong Process

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

• Software Isolated Processes (SIPs)

• Contract Based Channels
• 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 Receives
Asynchronous Synchronous
block until specific message
arrives
Exchange Heap
 Design Overview

• Software Isolated Processes (SIPs)

• Contract Based Channels
• 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

3. Check for Conflicts

5. Verify Dependencies (Versioned)

7. Instantiate Compile-Time Reflection procedures

9. 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) SW Protection (Midori)

Run program in kernel mode Privileged instructions can be in
trusted functions in SIP

ABI functions can be in-lined into SIP

code at installation
 ABI

• ABI functions by feature 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
 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 the

Microkernel implementation.
– Servicing applications can be designated to specific cores easier
than 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

Message CPU Cycles

Size(bytes)
Midori 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
 Conclusion

Why is Midori termed as

“The Windows Killer”?
Thank You…
? ? ?
Any Questions…

? ?
?