Tzi-cker Chiueh Ganesh Venkatichalam Prashant Pradhan

1. Integrating segmentation and paging protection for safe efficient and transparent software extensions Tzi-cker Chiueh Ganesh Venkatichalam Prashant Pradhan Computer Science Department State University of New York at Stony Brook Presented by: Palash Kasodhan

2. Introduction • Introduces a hardware based mechanism for safely carrying out kernel and user application extension • Introduces a model called Palladium for Linux running on Intel hardware • Uses segmentation and paging support in Intel hardware. • Makes use of variable length segments and different privilege levels for each segment.

3. Concept • Main Idea : Put core of the application/kernel and the extensions in disjoint segments at different privilege levels.So extensions cant access the core without proper authorization. • Requires modification to pointers as base addresses of core and extension become different. • An acceptable overhead for kernel programming but not for user applications.

4. Architecture refresher • Segment privilege levels vary from SPL0 to SP3 • Page privilege levels vary from PPL0 to PPL1 • Default : SPL0 to SPL2 map to PPL0 and SPL3 to PP1 • i.e. pages at SPL3 cant access those at PPL0 • Application can change SPL only by invoking a kernel service via interrupt gates.

5. Linux Refresher 4G B Kernel code segment SPL=0 PPL=0 Kernel Data/Stack Segment SPL=0 PPL= 0 • Size of virtual address space 4GB • Kernel address space : 3 to 4 GB • User address space: 0 to 3 GB • User: Text: 0 to 3 GB • Data/Stack: 0 to 3 GB • Kernel: Text: 3 to 4 GB • Data/Stack: 3 to 4 GB • Kernel segment part of every user process but accessible only via interrupt gates. Kernel 3 GB Stack Relocated Shared library User code segment SPL=3 PPL=1 User Data/Stack Segment SPL=3 PPL=1 User data, stack, code an tables 0 GB Layout of a Linux process’s virtual address space

6. Assumptions • Core program protected from extensions and not vice-versa • Extensions are protected function calls that are single threaded and always run to completion • User extensions can access only certain system calls as exposed by the core • Kernel extensions can access only certain core kernel services as determined by kernel

7. Implementation of Safe Kernel Extensions • Extensions based on dynamically loading modules using Insmod • Make use of the segmentation hardware support • Modules are allocated in new extension segments allocated in the 3 to 4 GB range • Extension segments have SPL = 1.So kernel can access them directly and not vice versa

8. Kernel Extension Implementation – contd. 4G B • As usual modules register with kernel the services they can offer • In a regular system a module has access to all kernel services • Palladium allows modules to use only a restricted set of kernel services, exposed via an interface Kernel Kernel extension segment SPL =1 PPL =0 Kernel Code and Data/Stack Segments SPL=0 PPL=0 Extension- 1 Kernel extension segment SPL =1 PPL =0 Extension- 2 3 GB User 0 GB Layout of a Linux process’s virtual address space in Palladium having kernel extensions

9. Implementation of User Level Extension • We don’t use the previous approach due to following reasons: • Difficult to share code and data , due to the requirement of pointer swizzling • Will require modification to relocation routines as they assume a linear address space starting from 0. • We adopt a approach based on using both segmentation and paging hardware support

10. Implementation of User Level Extension –contd. • By default an application starts at SPL= 3.An extensible application promotes itself to SPL=2 via system call • Creates a new segment for the extension in the 0 to 3 GB range with SPL=3 and PPL=1 • Application changes the PPL of pages it wants to share to PPL=1

11. Implementation of User Level Extension –contd. 4G B SPL=0 PPL=0 Kernel • Segmentation checks ensure that application isn't able to access kernel code . • Paging support ensures that extensions can only access their own code and the part of core exposed by application • Since base address is same we no longer need to swizzle pointers 3 GB User extension segment SPL =3 PPL =1 Extension- 1 User Code and Data/Stack Segments SPL=2 PPL=0 User extension segment SPL =3 PPL =1 Extension- 2 SPL=2 PPL=1 Shared User extension segment User 0 GB Layout of a Linux process’s virtual address space in Palladium having user level extensions

12. Implementation of User Level Extension –contd. • Problems related to transfer of control between core and extension : • Intel hardware doesn’t allow a higher privilege to call a function from lower privilege level segment.Control can only return from higher to lower privilege level. • Solution: So we use stub/wrapper functions as shown : Use lret ‘return’ Local call Local call Core Prepare Transfer Extension Use lcall ‘call-gate’ mechanism Local call Local call

13. Performance Issues • Performance overhead comprises of cost of invoking an extension function and one time module loading time. • A large part of inter-domain procedure call overhead is due to time taken to return control to the application core core from an extension because of extra checks while changing from SPL = 3 to SPL=2 • At the time of implementation offered the fastest protection domain switching overhead

14. Comparison with competing techniques • Other possible techniques are : • Type safe languages, Proof Carrying code, S/W fault isolation • All the above are based on software. • Have high run-time overhead. • Lack programming simplicity.