1 / 33

MIDORI

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

barbie
Download Presentation

MIDORI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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… ? ? ? ? ? ?

More Related