Midori Presentation
description
Transcript of Midori Presentation
MIDORIThe Windows Killer!!
by-Sagar R. Yeole
Under the guidance of- Prof. T. A. Chavan
Overview
1. Introduction to Midori O/S
2. Design Methodologies
3. Micro Kernel
4. Software Isolated Processes
5. Communication Channels
6. Manifest-Based Programs
7. Compile-Time Reflection
8. Heterogeneous Multiprocessing
9. Programming Languages Used
10. Performance
11. 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 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– 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 Channels
3. 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 Synchronousblock 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– 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 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
MessageSize(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
Why is Midori termed as“The Windows Killer”?
Conclusion
Thank You…
Any Questions…
??
??
?
?