1. MIDORI The Windows Killer!! by- Sagar R. Yeole Under the guidance of- Prof. T. A. Chavan

2. 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

3. What is Midori ?

4. “ What would a software platform look like if it was designed from scratch, with the primary goal of improved dependability and trustworthiness? “

5. What is the need for a new Operating System?

6. 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

7. 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

8. Design Methodology Written in Sing#(strongly typed “safe” language) Microkernel Architecture 1.Software Isolated Processes (SIPs) 2.Contract Based Channels 3.Metadata Infrastructure

9. 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

10. Design Overview 1.Software Isolated Processes (SIPs) 2.Contract Based Channels 3.Metadata Infrastructure

11. Software Isolated Processes(SIP) Shared address space for everything Everything is a isolated process Closed object / code spaces. No dynamic code execution

12. 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

13. 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

14. 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 Midori91346803352,873 Free BSD87891113,3041,032,254 Linux4379065,797719,447 Windows6277536,3445,375,735

15. Design Overview 1.Software Isolated Processes (SIPs) 2.Contract Based Channels 3.Metadata Infrastructure

16. 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

17. Exchange Heap

18. Design Overview 1.Software Isolated Processes (SIPs) 2.Contract Based Channels 3.Metadata Infrastructure

19. 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

20. 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)

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. Disk Performance: Read

29. Disk Performance: Write

30. Inter Process Communication Cost Message Size(bytes) CPU Cycles MidoriLinuxWindows 49335,5446,641 169285,3796,600 649425,5496,999 2569295,5197,353 1,0249265,97110,303 4,0969198,03217,875 16,38492819,16747,149 65,53692087,941187,439

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

32. Thank You…

33. Any Questions… ? ? ? ? ? ?