Transcript Midori Presentation

MIDORI
The Windows Killer!!
bySagar R. Yeole
Under the guidance ofProf. T. A. Chavan
Overview
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
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
1. Software Isolated Processes (SIPs)
2. Contract Based Channels
3. 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
1. Software Isolated Processes (SIPs)
2. Contract Based Channels
3. 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
1. Software Isolated Processes (SIPs)
2. Contract Based Channels
3. Metadata Infrastructure
Channels
•
Only way for SIPs to communicate
–
•
Each channel is
–
–
•
Needs to be fast (unlike current systems)
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
1. Software Isolated Processes (SIPs)
2. Contract Based Channels
3. 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
–
•
Follows principle of least privilege
–
–
•
API- source code compatibility; ABI- OS compatibility
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
ABI functions by feature
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…
?
?