Extensible KernelsOS Kernel TypesMotivationsApproachesExokernel: OverviewExokernel: OS Component LayoutA Motivating ExampleThe Reality …If Exokernel is Used…Exokernel: Design PrincipleExokernel: Secure BindingsSecure BindingsSecure Bindings via Downloading CodeMore on ASHsIssues in Resource RevocationExperiment: Aegis & ExOSProcedure and System CallsProtected Control TransfersExOS: IPC, VMASH: ScalabilityConclusionSome IssuesSPIN: an Extensible OSTraditional OSesSPIN StructureThe Protection ModelThe Extension ModelCore ServicesCore Services: Memory ManagementCore Services: Thread ManagementPerformance I: CompetitorsPerformance II: MicrobenchmarksVM primitivesPerformance III: NetworkingEnd-to-End PerformanceIssues in SPINSlide 37Extensible KernelsMingsheng HongOS Kernel TypesMonolithic KernelsMicrokernels–Flexible (?)–Module Design–Reliable–SecureExtensible Kernels–Can be customized (extended, specialized, replaced)More functionalityBetter performanceMotivationsProblems in traditional OS kernels–Implementation cannot be modifiedLRU as general page replacement strategy–Hide information of machine resourcesNot always appropriate in achieving high performance–database on top of file system–Provide a unified interface (overly general)Trade-offs for different applications–page table structureApproachesExokernel: safely expose machine resources –Higher-level abstractions are implemented in applications–The concept of Library OS–Safety ensured by secure bindingsSPIN: use kernel extensions to safely extend/change OS services/implementations–Event-driven model to customize services–Efficiency preserved–Safety ensured by PL facilitiesExokernel: OverviewAn extension of RISC philosophyKernel provides minimum services–Hardware resource protectionAllocationRevocationSharingTracking of ownership–Resource usage arbitrationIncluding an abort protocolLibOS as powerful as traditional OSExokernel: OS Component LayoutExokernelA Motivating Example*This example is borrowed from MIT websiteThe Reality …If Exokernel is Used…Exokernel: Design PrincipleTo separate protection from management–Can protect resources without understanding themWhen knowledge of resource is required–Can leave decisions to applications by downloading code–Another level of indirection without sacrificing performanceExokernel: Secure BindingsWhy?–Library OSes are untrustedHow?–Hardware mechanismTLB entry–Software cachingSTLB–Downloading application codeSecure BindingsMultiplexing physical memory–Records capabilities: ownership, R/W permissions (authorization at bind time)–Checks capabilities(authentication at access time)–Enables resource sharing (How?)Secure Bindings via Downloading CodeMultiplexing the network–Uses Application-specific Safe Handlers (ASHs)–PerformanceEliminate kernel crossingsDecouple latency-critical operations from process scheduling–SafetyCan be verified and trustedMore on ASHsAn ASH can serve as a–Packet filter–Computation unitchecksumming–Message initiator–Control initiatorIssues in Resource RevocationVisible deallocation of resource–So that library OS has a chance to reacte.g. when physical page “5” is deallocated–But could be less efficientCan combine invisible revocationLibrary OS can be prepared for such occasionsBut when application does not cooperate…–Abort Protocol – imperative revocatione.g. cpu time sliceNeed to leave some resource for each libOS–Guaranteed mappingExperiment: Aegis & ExOSAegis: an exokernel on MIPS-based DECstation–Xok: another exokernel for Intel x86 computersExOS: the corresponding library OS–Virtual memory, IPC are managed at application level–Can be extendedPerformance compared with: UltrixProcedure and System CallsProtected Control TransfersSuggested reasons (?)–Kernal crossing–TLB flushExOS: IPC, VMASH: ScalabilityConclusionSecurely multiplexes hardware resources, to achieve more flexibility & efficiency–OS primitives–High level abstractions: VM, IPC–Implementation can be customized (libOS)Some IssuesExokernel–PortabilityLibrary OS–Too much code in user space?–Not easy to customize?OSKit, SPIN–Should provide a standard interface?–SecuritySPIN: an Extensible OSUses language features to make a system–ExtensibleDynamic linking & later binding–SafeType safe language–EfficientIn kernel spaceModula-3 features: memory safe; interfacesTraditional OSes*This picture is borrowed from Univ. of Washington websiteSPIN Structure*This picture is borrowed from Univ. of Washington websiteThe Protection ModelPointers as capabilities–Types not forgeable–Determined at compile-time => efficient–Externalized when passed across domainsAn object is safe if–Verified by the compiler–Or asserted so by the kernel (objected implemented in other languages)The Extension ModelEvents and handlerseventhandlersP1P2P3Execution of handlers can be•Synchronous/ asynchronous•Bounded in time•Ordered/unorderedpredicatesCore ServicesServices that cannot be safely implemented by extensionsSimple functionalityFine grained controlCore Services: Memory ManagementManage memory and processor resources–MM interfacesStorage: allocate, deallocate, reclaimNaming : allocate, deallocateTranslation: add/remove/examine mapping–ExceptionsPageNotPresentBadAddressProtectionFault–Address space model can be defined on top of the primitivesCore Services: Thread ManagementThread Management–Strand interfaceblock/unblockcheckpoint/resume–Global and application-specific schedulers–Thread model can be defined on top of the primitivesCore services are t rusted–Extensions should be fault-isolatedPerformance I: CompetitorsDEC OSF/1: monolithic kernelMach 3.0: microkernelSPIN: extensible kernelPerformance II: MicrobenchmarksIPCThread managementVM primitives•Kernel crossings•Overhead in demultiplexing exception (?)Performance III: NetworkingLatency and bandwidthPacket forwardingEnd-to-End PerformanceNetworked Video SystemA dilemma in web server buffer management-- hybrid cache policyIssues in SPINScalability of the event/handler modelHow to prioritize handlers?–Throughput vs. fairnessExtensibility limited by interfacesConclusionTwo methods to make OS more flexible &
View Full Document