MIDORI The 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

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 FactorsMonolithic kernelMicro kernel SizeHugeSmall IPCSignals/SocketsMessage queues SecuritySystem-wide haltLocal process hale CorrectnessHard to ensureEasier to ensure I/O CommunicationFully integrationMessage-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 based protection mechanisms 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: System Cost(in CPU Cycles) API Call Thread Yield Message Ping/Pong Create Process Midori ,873 Free BSD ,3041,032,254 Linux ,797719,447 Windows ,3445,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: SendsReceives AsynchronousSynchronous 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 – 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 FeaturesFunctions Channels22 Child Processes21 Configuration25 Debugging & Diagnostics31 Exchange Heap8 Hardware Access16 Linked Stacks6 Paged Memory17 Security Principals3 Threads & Synchronization43 Total192 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 Message Size(bytes) CPU Cycles MidoriLinuxWindows 49335,5446, ,3796, ,5496, ,5197,353 1, ,97110,303 4, ,03217,875 16, ,16747,149 65, ,941187,439

Why is Midori termed as “ The Windows Killer”? Conclusion

Thank You…

Any Questions… ? ? ? ? ? ?