Midori Presentation

MIDORI The Windows Killer!!

bySagar R. Yeole

Under the guidance ofProf. 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 –

•

Execute independently- each has own: – – –

•

Language safety and verification tools in SW

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

• Partitioned into:

 Kernel Object space  Object spaces for each SIP  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

Midori

API Call

Thread Yield

Message Ping/Pong

Create Process

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 –

•

Each channel is – –

•

bi-directional defined by exactly two endpoints

Each endpoint – –

• •

Needs to be fast (unlike current systems)

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 –

•

Follows principle of least privilege – –

•

SIPs do not have much default ability Gain access to higher-level systems through channels

Kernel ABI Strongly versioned –

•

API- source code compatibility; ABI- OS compatibility

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

CPU Cycles 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…

?

?

?