330 likes | 566 Views
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
E N D
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? “
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 doeschange? • 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 • Software Isolated Processes (SIPs) • Contract Based Channels • Metadata Infrastructure
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 • Partitioned into: • Kernel Object space • Object spaces for each SIP • Exchange heap • OS only needs one: • Error Recovery Model • Communications Mechanism • Security Architecture • Programming Model
SIP Cost • Inexpensive to create • Communication has low overhead • Cost comparison:
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:
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 • Load Manifest • Check for Conflicts • Verify Dependencies (Versioned) • Instantiate Compile-Time Reflection procedures • 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
ABI • 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 Chakrabortyet 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
Conclusion Why is Midori termed as“The Windows Killer”?
Any Questions… ? ? ? ? ? ?