MIDORI

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

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

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 doeschange? • 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 • Software Isolated Processes (SIPs) • Contract Based Channels • Metadata Infrastructure

9. Micro kernel

10. Design Overview Software Isolated Processes (SIPs) Contract Based Channels 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 • 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:

15. Design Overview Software Isolated Processes (SIPs) Contract Based Channels 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:

17. Exchange Heap

18. Design Overview Software Isolated Processes (SIPs) Contract Based Channels 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 • Load Manifest • Check for Conflicts • Verify Dependencies (Versioned) • Instantiate Compile-Time Reflection procedures • 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

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

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

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

32. Thank You…

33. Any Questions… ? ? ? ? ? ?