An Enhanced Multi-Pager Environment Support for Second Generation Microkernels
AAn Enhanced Multi-Pager Environment Supportfor Second Generation Microkernels
Yauhen Klimiankou
Department of Information Technologies Software, Belarusian State University of Informatics and RadioelectronicsMinsk 220 113, Belarus [email protected] | [email protected]
Abstract —The main objective of this paper is to present amechanism of enhanced paging support for the second generationmicrokernels in the form of explicit support of multi-pagerenvironment for the tasks running in the system. Proposedmechanism is based on the intra-kernel high granularity pagersassignments per virtual address space, which allow efficient andsimple dispatching of page faults to the appropriate pagers. Thepaging is one of the major features of the virtual memory,which is extensively used by advanced operating systems toprovide an illusion of elastic memory. Original and present secondgeneration microkernels provide only limited, inflexible andunnatural support for paging. Furthermore, facilities provided bycurrent solutions for multi-pager support on the runtime levelintroduce an overhead in terms of mode switches and threadcontext switches which can be significantly reduced. Limitedpaging support limits the attractiveness of the second generationmicrokernel based systems use in real-life applications, in whichprocesses usually have concurrent servicing of multiple pagingservers. The purpose of this paper is to present a facilities for theefficient and flexible support of multi-pager environments for thesecond generation microkernels. A comparison of the proposedsolution to the present architecture L4 + L4Re has been madeand overhead of the page fault handling critical path has beenevaluated. Proposed solution is simple enough and provides anatural and flexible support of multi-pager environments forsecond generation microkernels in efficient way. It introducesa third less overhead in terms of the mode switches and threadcontext switches in comparison to the present L4 + L4Re solutionimplemented in the Fiasco.OC.
Index Terms —memory management, page fault, second gen-eration microkernel, multi-pager environment
I. INTRODUCTIONThis paper describes the design of the fine-grained multi-pager environment support facilities for the second generationmicrokernels that allows processes running in the system tobe serviced by multiple pager servers concurrently and inefficient way. The proposed approach describes modificationsof the virtual memory management subsystem of the secondgeneration microkernels.The user mode page fault handling was originally proposedby the Mach project [1] [2]. The general idea of the proposedapproach is to allow the page fault handling servers to berunning as a separate user mode processes. Safe and efficientmemory management is a fundamental requirement for amicrokernel. Due to this, for example, substantial memory overhead imposed by originary recursive address space con-struction can be considered as an enough drawback to rejectthis memory management approach [3]. Traditional approachfor paging support in the L4 like microkernels family is limitedand not efficient for multi-pager environments, which areordinary for the advanced real-world systems and applications.Insufficient support of such environments limits the attrac-tiveness of second generation microkernel based operatingsystems for the real system implementations. Furthermore thisinsufficient support of paging looks inadequate to the actualstate of facts, because experience gained from the ubiquitousmonolithic kernels shows that the typical application arelikely serviced by multiple memory management subsystemsconcurrently. For example, the typical processes in Windows[4] and Linux [5] environment concurrently get the next ser-vices: automatic stack expanding/reducing, dynamically load-able modules management, anonymous memory management,unswappable memory management, shared memory manage-ment, file mappings to memory etc. Furthermore some specificapplications can wish to use special purpose memory man-agement facilities along with ordinary memory managementservices. For example they can wish to use SMARTMAP-like[6] memory management for performance benefits or InkTag[7] and Gateway [8] -like memory management features toachieve additional security and reliability guarantees.Nevertheless of the extensive use of the multi-pager en-vironments in typical applications present second generationmicrokernels have a limited support of it. The original ap-proach taken by the L4 microkernels family [9] is an optionalassignment of exactly one pager for each task running inthe system. This pager is responsible for handling of allpage faults generated by the tasks to which it is assignedas a pager. The same approach is kept in the descendantkernels like [10]. Present version of the L4 (Fiasco.OC) [11]provides a tricky support of multi-pager environments throughintroduction of the additional level of indirection - regionmapper. This solution has been done on the level of runtimeenvironment system L4Re [12] developed specially for the L4microkernel in the Technical University of Dresden. In otherwords, this solution is an attempt to overcome limitationsimposed by the single-pager kernel design on the level ofruntime environment instead of changing kernel itself, despite a r X i v : . [ c s . O S ] A p r he fact that the kernel is a natural location for multi-pagerenvironment support and that this support can be implementedin the kernel in efficient way and only with negligible violationof the minimality principle.Region mapper is an additional layer of indirection in pagefault handling introduced by L4Re for providing a multi-pager environment for applications running in the context ofthis runtime environment. According to this solution, eachprocess running in L4Re environment has a special threadrunning inside it, which plays a role of pager for all otherthreads running in the same process (threads that share thesame virtual address space). This special thread of L4Re-basedprocess is called a region mapper. Its main responsibility is tomanage a virtual address space layout through virtual memorymanagement and page fault handling. Region mapper do thisby managing a special table which tracks which region of thevirtual address space is serviced by which memory manager.By using this table region mapper is able to route the pagefaults generated by process threads to the appropriate externalmemory manager server. As a result, the typical page faulthandling process goes through next steps:1) Page fault is generated by a thread.2) CPU interrupts the faulted thread and gives control tothe L4 microkernel.3) L4 looks at the faulted thread to identify, which threadis a pager of it (it is a region mapper for L4Re basedprocesses).4) L4 suspends the faulted thread and sends page faultmessage for the region mapper.5) The region mapper looks into the table by using the faultaddress to find out a thread which is responsible for thefaulting address as a real pager.6) The region mapper reflects the page fault message to thereal pager.7) The real pager takes an actual actions to resolve the pagefault reason and restart the faulted thread.Region manager relies to the generic abstraction of memorymapping which is called dataspace, that was initially intro-duced as a part of SawMill VM framework [13]. Dataspaceis a generic source of resources capable to be mapped as acontinuous memory region to the virtual address space likeanonymous memory region, memory mapped file or device,etc., and provides only generic memory management func-tionality. Dataspace is a capability-protected interface imple-mented by L4Re but its actual implementation is providedby external thread called dataspace manager, which is incharge of the dataspace layout and its content. As a resultmultiple dataspaces with different implementations managedby different servers can coexist in the system concurrently.Besides handling page faults generated by threads attached toit, region mapper is also responsible for maintaining layout ofthe virtual address space which it services. That means thatit is responsible for inserting and removing of the dataspacesto/from virtual address space. And due to this it is capableto add/remove appropriate entries to/from the mapping table mentioned above to maintain it in actual and consistent state.The actual virtual address space region represented by datas-pace is populated by pages through page faults reflected bydataspace manager.The described existing mechanism for providing the multi-pager environment in the L4 family of second generationmicrokernels is complex and inefficient, because it involvesmultiple context switches for such typical tasks as page faulthandling. We would like to propose more natural, simpleand efficient way of multi-pager environment support for thesecond generation microkernels, which moves this supportimplementation from the runtime environment layer into thekernel. Proposed approach introduces less processor timeoverhead and memory overhead with only negligible violationof the minimality principle, which can be advocated by thesame arguments which are applied for intra-kernel schedulingpolicies implementation.II. VIRTUAL MEMORY ANDPAGE FAULT HANDLINGEmergence of the virtual memory technology made a greatimpact on the whole future computer systems development.The two most significant ideas behind virtual memory are:1) Arbitrary mappings between hardware memory layoutand memory layout observed by applications.2) Transparent changing of mappings between hardwarememory and memory layout observed by applications.Both ideas rely to the explicit support of the virtual memoryby underlaying CPU architecture. Significance of the virtualmemory technology can be stressed by the fact that CPU usesspecially dedicated block called MMU for its support. In thefollowing discussion we will focus on the second major ideaof the virtual memory which is widespread called paging.From the paging point of view, typical system can be splitinto two domains: memory resource providers and memoryresource consumers, relationships between which are mediatedby CPU. This mediation comes in two forms: present flag inpage table entry and page fault exception. The first one allowsto mark virtual memory pages as stubs, which haven’t anyactual resources assigned. And the second one implementsa way according to which the memory resource managercan be notified about attempt to access stub virtual memorypage. Both this features together provide a channel of im-plicit communication between memory resource provider andmemory resource consumer, which allows transparent dynamicmemory management, which memory consumer don’t needto take care about. Memory manager is able to silently getback memory allocated to consumer earlier or allocate someadditional memory to it. In the same time it can be silentlycalled by consumer in the case when it requires memory thatwas got back by memory manager before.Such reasoning and understanding of the paging in contextof the virtual memory lead us to a number of conceptualconclusions about paging nature. . There is only one manager per unit of physical addressspace represented resources When multiple memory managers can coexist in the systemconcurrently, each of them must manage its own resources, andeach resource unit in the system must be managed by exactlyone memory manager. The hierarchical memory managerschain implemented in L4 microkernels in which all chainentries manage the same region of memory is unnatural,overcomplicated. Furthermore the fact that the same threadcan play role of both memory manager and memory consumerfor the same memory unit completely violates original virtualmemory concept.
B. Relationships between memory consumer and memorymanager goes through a virtual address space region whichconsumer trust to manage to a specific manager
Primary communication channel between memory managerand memory consumer in virtual memory system is an implicitcommunication channel going through CPU with protocolwhich allows manager to silently give and return memoryto/from consumer virtual address space and allows consumerto silently request resources through page fault exceptions.Memory manager is trusted entity for the memory consumerby default, because it preserves access to all resources whichit provides to the consumer. But besides trust provided to themanager in regard to access to the data stored in memory,consumer must provide it a trust of virtual address spacemanagement. The only consumer responsibility is to chooseto which memory manager it trusts and which region of itsvirtual address space.
C. Memory manager and page fault handler is a single entity
Virtual memory model assumes that the actions that aretaken in reply to the page fault exception is targeted to provideresources requested by exception trigger and restart the triggerthread execution. Due to the fact that the resource providingis a responsibility of memory manager, page fault handlingis its natural responsibility too. There is no big sense todistinguish memory manager and page fault handler as twodifferent entities.
D. Multi-pager environment is natural for advanced operatingsystems
During long history of the virtual memory based operatingsystems a lot of ways of virtual memory usage have beendemonstrated. Examples of these ways includes swappableand unswappable memory allocation, memory-mapped filesimplementation, IO devices access management, security andprocess isolation, shared memory management, intelligentDLL management etc. Multi-pager environment is commonlysupported in the widespread industrial OS like Windowsand Linux and this support is extensively used by advancedapplications. III. DESIGN AND IMPLEMENTATION OFMULTI-PAGER ENVIRONMENT SUPPORT
A. Virtual address space management
Proposed model of multi-pager environment support intro-duces a fundamental abstraction - user space region. Userspace region is a fixed size continuous part of user part ofvirtual address space. User space part of virtual address spaceis split into a fixed number of regions, each of which containsa fixed number of pages. In our experimental system we have1020 regions per virtual address space and 1024 pages perregion. Due to this our model shown in figure 1 resemblesmemory management architecture of Intel x86 [14], whereregion can be considered as an counterpart of the directoryand represents 4 Mb window of virtual address space.User space region is a fundamental unit of virtual addressspace management granularity. Each user space region canbe managed by independent manager. Region manager haverights to map and unmap resources owned by it into any placein the managed region without any restrictions. As a result itcan do this completely transparently to any thread running inthe context of virtual address space witch contains that region.Region manager plays both roles: memory manager andpager for the regions assigned to it. Due to this on the onehand all page faults occurred in the region are transparentlyrouted for handling to the region manager assigned to it, andon the other hand that region manager can transparently replyto the page fault by mapping resources requested by it intothe appropriate place of the region affected.Threads running the context of virtual address space areresponsible only for assigning region managers for each par-ticular region of its virtual address space. By assigning themanager for the region thread provides to it trust of this regionmanagement and is unable to control particular mappingsand unmapping operation. Due to the fact there are multipleregions in the same virtual address space and managers areassigned to them independently, in result proposed model rep-resents a natural multi-pager environment with good enoughmanagement granularity.Implementation of the proposed model introduces memoryoverhead in 4Kb per virtual address space. Kernel incorporatesregions table into the virtual address space abstraction imple-mentation. Region table is implemented as a memory pagewhich contains an array of thread ids of region managers. Toeach user space region with sequential number N correspondsthe regions table entry with the same sequential number.Regions table itself is mapped into the kernel part of thevirtual address space which is located on a fixed address. Asa result during page fault kernel can easily find the regiontable itself and identify the region manager responsible for theregion to which fault address belongs, and to which kernel willsend a page fault notification message. User space region idcorresponding to a virtual address belonging to a user spacepart of virtual address space can be easily found using the nextformula:
RID = ( A v − B us ) /RS, (1) Fig. 1. Page Faults Dispatching where RID is a region sequential number, A v is a virtualaddress to which this RID corresponds, B us is a base addressof user space part of virtual address space and finally RS is asize of region. Note that the B us and RS is a constants definedby the system design. Note also, that if RS is represented byvalue which is equal to power of two (which is a case of ourimplementation) the costly division operation can be replacedby cheap bit shift operation. B. Page fault handling
Exceptions are a natural class of system events about whichkernel must take care. In accordance with spirit of secondgeneration microkernel design the actual work of the exceptionhandling must be pushed out into user space and kernel mustonly dispatch the exception handling activities provided byexternal user mode servers. Due to this our experimental kerneldoesn’t distinguish exceptions of different types and handlesthem in the uniform way.Despite the fact, that in proposed model kernel doesn’tdistinguish different types of exceptions and deals with allthem in uniform way, the page fault exception is consideredby it as a very special type of exceptions as shown in figure2. For page faults kernel provides an additional zero level ofhandling and skips all other levels of handling in the case ofsuccess on that zero level.At zero-level kernel next distinguishes two types of pagefaults: pure page faults and general protection page faults.The first ones are faults for addresses belonging to the userpart of virtual address space and generally eligible from theprotection point of view. The second ones are an faults foraddresses outside of the user part of virtual address space.The kernel takes special handling only for the pure page faultsand consider the another page faults as a general protectionfaults which are an example of the generic exceptions thatmust be handled in the ordinary way. By this kernel can
Hardware Events ExceptionsSystem CallsHardware Interrupts Page FaultGeneric Exceptions Pure Page Fault2 1
Fig. 2. Page fault classification separate out faults that clearly aren’t related to the paging andrepresent a clear protection violation attempt like null pointerdereferencing or attempt to access kernel code or data.Not all pure page faults are serviced by appropriate pagers.There are two exceptional cases:1) Faulted virtual address belongs to the virtual addressspace region which has not pager assigned.2) Faulted virtual address belongs to the virtual addressspace region which has pager assigned but the assignedpager didn’t accept the servicing of that region.The first exceptional case is a result of multi-pager environ-ment support. There is no single pager assigned to the thread,which is responsible for handling all page faults triggered bythis thread despite the nature of page fault. Instead there issingle virtual address space split into multiple regions, each ofwhich can have pager assigned. As a result the virtual addressspace can be sparsely populated space, some regions of whichare assigned to the pagers, and the rest have not any pagersassigned. Page fault triggered in reply to attempt to access thesecond ones are considered as a general protection faults.The relationships between memory provider task (pager)and memory user task are based on the contract. To establishthis relationships agreements of both sides must be receivedby the kernel. Memory user task provides this agreement byexplicitly assigning the specified pager task to a particular vir-tual address space region. Memory provider task provides thisagreement implicitly by taking memory management actionon the region assigned to it. Furthermore pager can revokeits agreement by removing last piece of memory from theparticular region with REVOKE AGREEMENT flag specifiedin the system call. As a result pager task can protect itselffrom the malicious or misbehaving memory user task whichtoo frequently generates page faults and by this performs DoSattack on the pager. But from the other hand this featureintroduces the second exceptional case on which the pagefault is generated on the region which isn’t accepted by thepager. This case is also considered by the kernel as a generalprotection page fault.The last check which can take place before invoking anappropriate pager is checking of the actual not presence ofthe appropriate memory page. On the x86 platform it canbe done by checking PAGE PRESENT flag in the page tableentry denoting page on which page fault occurred. This lastcheck introduces negligible overhead, because according toour memory management subsystem implementation, kernelalways reads page table entries during page fault handlingto get 31-bit pager defined marker from the page table entrycorresponding to the faulted page. This check can have sense,ecause there are multiple threads running in the same virtualaddress space allowed, which can potentially fault in the samepage in very little period of time. As a result the situations arepossible, in which the faulted page can be restored by the pagerbetween page fault and actual pager invoking.Let’s consider the case illustrated on Fig. 3. In this case,there are two threads A and B concurrently running in thesame virtual address space. Each of them made page fault onthe same page N sequentially one after another. But threadA and thread B achieved different handling from the kernelside. Kernel notified pager that thread A triggered page faulton page N via message and blocks thread A execution untilpager will have page N restored. Then when pager got a CPUtime it restored mapping of the page N and unblocked threadA, allowing it future execution.The case of thread B differs from the case of thread A inthe fact, that between actual page fault generation and the endof first phase of page fault handling, pager has scheduled forCPU time and already restored mapping of the page N. As aresult, kernel can simply and safely return control back to thethread B without its blocking/unblocking and additional pagerinvolving.IV. CASE STUDY, PRELIMINARY EVALUATIONAND DISCUSSIONLets consider three page fault handling schemes used inmulti-pager environment supporting operating systems: mono-lithic kernel approach, Fiasco.OC approach and finally pro-posed approach (Fig. 4). For each case we consider a usermode thread that triggers a page fault exception which mustbe handled by paging server to allow the faulted thread tocontinue its execution. We consider a general path of the pagefault handling without taking into the account the performancepenalty introduced by paging server, cost of transition betweenkernel mode and user mode and cost of IPC.Originally, the first proposed page fault handling cyclewas proposed for monolithic kernel design. According to thisapproach all the page fault handling activities are performed inthe kernel. Kernel is the only paging server of the system andcan be considered as a tightly integrated set of subsystems,which includes multiple paging modules. Due to this wecan consider monolithic kernel as a multi-pager environmentprovider. Page fault handling cycle in the environment ofmonolithic operating system includes two crossing of thekernel mode/user mode boundary: one is triggered by pagefault exception and the second one is to return the controlflow to the faulted thread. All page fault resolution actionsare performed in the kernel without involving another threads.This page fault handling scheme is the most efficient, but notapplicable for the second generation microkernel design.The key design principle used in the first second generationmicrokernel L4 was a minimality principle, in accordance towhich as much as possible functionality was pushed out fromthe kernel. Page fault handling is a part of functionality thatwas removed from the kernel. Instead of full-featured pagefault handling kernel only dispatches page fault exceptions generated by CPU through message passing to the dedicatedpage fault handling server thread. This thread called pager isexplicitly assigned to the threads running in the system on theone pager per thread basis. As a result, pager is wired not tovirtual address space but to thread and it is responsible forhandling all page faults generated by the thread to which itwas assigned. Page fault handling cycle of the L4 is similarto the same in Mach and includes four crossings of the kernelmode/user mode boundaries and two thread context switches.But as you can see there is no multi-pager environment supportimplemented in the kernel.The researchers from TUD noted multi-paging importanceand proposed to implement its support on the level of runtime.They implemented this support in L4Re runtime, which createsa special pager thread per process and assigns it as a pagerfor each thread running in the same process. This pager threadmaintains the database of mappings between virtual addressspace regions and pagers assigned to it. Page fault handlingcycle in this case includes 6 crossings of kernel mode/usermode transitions and 3 thread context switches. At the firststep CPU switches from user to kernel mode in reply to pagefault exception triggered by running thread A. Kernel in replysuspends thread A and sends page fault message to the L4Repager task assigned to task A. Pager in its turn consults withmapping database and figures out which task is responsible forresolution of page fault. Pager resends (reflects) the initial pagefault message to the actual pager identified on the previousstep. After this the actual pager finally can perform the actionsfor actual servicing of the page fault of task A.
TABLE ICOMPARISON OF PAGE FAULT HANDLING IN DIFFERENTMULTI-PAGER ENVIRONMENTS
Architecture Mode switchcount Contextswitch count
Monolithic kernel 2 0Proposed approachSingle-paging L4Mach 4 2L4 Microkernel +L4Re (Fiasco.OC) 6 3
Proposed approach preserves the same page fault handlingcycle as an original L4 kernel, but with natural intra-kernelsupport of multi-pager environment. On the other hand it issimilar to the simplified page fault handling scheme of theMach microkernel acceptable for the second generation mi-crokernels. Page fault triggered by the thread causes transitionfrom the user mode to kernel mode where kernel at the finalstep of its dispatching identifies the pager thread assigned tothe region of address space which the faulted address belongsto. Then similar to other exception handling it suspends thefaulted thread and sends page fault description message tothe pager identified. After resolution of the page fault, pagernotifies the kernel about resolution results and by this resumesfaulted thread. Page fault handling cycle is accomplished byassing control back to the resumed thread. As a result fourtransitions between kernel and user mode and two threadcontext switches are required by proposed approach for pagefault handling cycle. Results are summarized in table I.Proposed approach allows to reduce overhead of the pagefault handling in terms of mode switch and thread contextswitch by 33.3% while preserving multi-pager environmentsupport. In the same time it introduces only a very littleadditional code complexity and incurs only 4Kb of mem-ory overhead per virtual address space. But note that L4 +L4Re approach preserves similar per address space memoryoverhead but on the runtime level, because code of the L4Retask and mapping database is enforced to be located on theunswappable memory, as it must eliminate page faults whichcan be triggered by L4Re pager thread itself.In fact the proposed approach can be criticized from thepoint of view of minimality principle. But it can be advocatedby the same arguments which was used for the advocationof the intra-kernel scheduling. Indeed, microkernel looks likea natural location for the multi-pager environment support.Additional code complexity is negligible and can be measuredby only a few hundreds bytes of code. Unfortunately we can’tprovide an exact number of additional microkernel footprintbytes because the prototype of the proposed approach hasbeen implemented as a part of written from the scratch kernelinstead of changing the original L4 microkernel. But notealso that despite the fact that it introduces memory overheadby one memory page per virtual address space the overallmemory overhead of the system is reduced. In contrast to theL4Re approach, there is no requirements for additional regionmapper task per virtual address space and resources used byit. Cost of the transition between kernel and user modes, intra-kernel exception dispatching, thread context switch and IPCare main contributors to the page fault handling overhead.Proposed approach adds only negligible overhead in lessthan dozen of simple processor instructions to the originalsingle-pager L4 page fault handling cycle critical path. Thisadditional overhead is much smaller than the cost of the tran-sition between kernel/user modes or thread context switcheswhich usually takes more then hundred processor cycles.Unfortunately fair comparison of the page fault handling costof original L4, Fiasco.OC and proposed approach is hard totake in our current environment, because in contrast to the L4microkernels our research kernel relies on the asynchronousIPC (reasons behind this design choice are out of the scope ofthis paper). But we believe that the analytical comparison anddiscussion of the proposed approach outlined in this paperis clear and sufficient to highlight benefits of the proposedsolution.In general by this paper we wanted to advocate return ofthe multi-pager environment support into kernel. This canbe considered as a step back to the Mach design, but withpreserving the general second generation design principles andchoices, and with entire simplification of the mechanisms usedin accordance with minimality principle. V. CONCLUSION AND FUTURE WORKSThe new way of the multi-pager environment support inthe context of second generation microkernel based operatingsystems is proposed and described. It is showed that thedemonstrated mechanism is superior because it introduces lessoverhead through reduction of number of mode switches andthread context switches performed during page fault handlingcycle, provides more simple design and more flexible andnatural environment for the system building. Despite thefact that this way of multi-pager support introduces someadditional code complexity, this complexity is very small andcan be advocated by the same arguments used for kernel-levelscheduling advocation. Future work can be done on the base ofthis approach to explore other aspects of memory managementin the context of second generation microkernels and designsof the full-featured multi-pager environment that can be builtin the user mode using the proposed multi-pager support inmicrokernel. R
EFERENCES[1] M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian,and M. Young, “Mach: A new kernel foundation for unix development,”1986, pp. 93–112.[2] S. Sechrest and Y. Park, “User-level physical memory management formach.” in
USENIX MACH Symposium . USENIX, 1991, pp. 189–200.[3] K. Elphinstone and G. Heiser, “From l3 to sel4 – what have we learnt in20 years of l4 microkernels?” in
ACM SIGOPS Symposium on OperatingSystems Principles (SOSP) , Farmington, PA, USA, November 2013, pp.133–150.[4] M. Russinovich and D. A. Solomon,
Windows Internals: Including Win-dows Server 2008 and Windows Vista, Fifth Edition , 5th ed. MicrosoftPress, 2009.[5] D. Bovet and M. Cesati,
Understanding The Linux Kernel . Oreilly &Associates Inc, 2005.[6] R. Brightwell, K. Pedretti, and T. Hudson, “Smartmap: Operatingsystem support for efficient data sharing among processes on a multi-core processor,” in
Proceedings of the 2008 ACM/IEEE Conference onSupercomputing , ser. SC ’08. Piscataway, NJ, USA: IEEE Press, 2008,pp. 25:1–25:12.[7] O. S. Hofmann, A. M. Dunn, S. Kim, M. Z. Lee, and E. Witchel,“InkTag: Secure applications on an untrusted operating system,” in
Proceedings of the Eighteenth International Conference on ArchitecturalSupport for Programming Languages and Operating Systems (ASPLOS) ,March 2013.[8] A. Srivastava and J. T. Giffin, “Efficient monitoring of untrusted kernel-mode execution.” in
NDSS . The Internet Society, 2011.[9] J. Liedtke, “On microkernel construction,” in
Proceedings of the 15thACM Symposium on Operating System Principles (SOSP-15) , CopperMountain Resort, CO, 1995.[10] G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin,D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell,H. Tuch, and S. Winwood, “sel4: Formal verification of an os kernel,”in
Proceedings of the ACM SIGOPS 22Nd Symposium on OperatingSystems Principles , ser. SOSP ’09. New York, NY, USA: ACM, 2009,pp. 207–220.[11] The fiasco microkernel - overview. [Online]. Available: http://os.inf.tu-dresden.de/fiasco/[12] L4re – the l4 runtime environment. [Online]. Available: http://os.inf.tu-dresden.de/L4Re/[13] M. Aron, Y. Park, T. Jaeger, J. Liedtke, K. Elphinstone, and L. Deller,“The SawMill framework for VM diversity,” in
Proceedings of the 6thAustralasian Computer Systems Architecture Conference . Gold Coast,Australia: IEEE CS Press, jan 2001, pp. 3–10.[14] Intel Corporation,
Intel Architecture Software Developers Manual Vol-ume 3: System Programming . Santa Clara, CA, USA: Intel Corporation,1999. xecution A Execution Execution Restoring of Page N B Execution
Task ATask BPagerKernel B
Page Fault on Page NTask B was Preempted by Pager Task B Continue ExecutionPager preempted by Task B Task A Continue ExecutionPage Fault on Page N Task A is BlockedTask A is BlockedTask A was preempted by task B Task A is UnblockedPager Restored Page N
Fig. 3. Concurrent Page Fault Handling Case
Task A Kernel Router Kernel KernelPager Task A
Page fault PF NotificationReflection PF NotificationResolve mapping Continue
Task A Pager Task ATask A Task A
Page fault
Kernel modeUser modeKernel modeUser modeKernel modeUser modeContext switch Context switch Context switch
L4MICROKERNEL
PROPOSEDSYSTEM
MONOLITICKERNEL CS/MS3/6
CS/MS2/4
CS/MS0/2
Kernel
PF NotificationPage fault
Kernel
ContinueResolve mapping
Kernel