Programming Assignment 2
\n(GemOS Kernel Programming)
\nCS962: Operating System Principles
\n2023-24 Q3 eMasters in Cyber Security
\nDepartment of Computer Science and Engineering<\/p>\n
Due Date: 06th March 2024, 11:55pm
\nIntroduction
\nThe objective of this assignment is to expose you to OS memory management concepts covered in the lectures. You will be implementing memory-related system calls in gemOS.
\nThe gemOS source can be found in the gemOS\/src directory. Structure of the gemOS\/src directory is as following:
\n\u2022 gemOS\/src\/user\/ contains the user space components of the gemOS.
\n\u2013 init.c is the userspace program that will run on gemOS. This program will interact with gemOS using system calls.
\n\u2013 lib.c is library that contains the implementation of common functions such as printf(). It is equivalent to the C library (libc) in Linux. (Not to be modified)
\n\u2013 ulib.h is a header file containing declaration of various functions and system calls. It is equivalent to the user space header files in Linux. (Not to be modified)
\n\u2022 gemOS\/src\/include\/ contains the header files related to the kernel space implementation of the gemOS. (Not to be modified)
\n\u2022 gemOS\/src\/*.c, *.o files contain the implementation of the kernel space of the gemOS. (Modify only the specified files)
\n\u2022 gemOS\/src\/Makefile is used to build the gemOS kernel binary gemOS.kernel. (Not to be modified).
\nBackground
\nThis section revisits some known along with additional concepts required to finish this assignment.
\nVM Area
\nA VM Area is a contiguous region in the virtual address space of a process. Each area is associated with a start address, end address, and some protection information. The mmap system call is used to allocate VM Areas.
\nPaging, TLBs, and Efficiency
\nYou are familiar with the concept of multi-level paging. Most operating systems implement pages of 4KB and the mappings between virtual pages and physical frames are stored in the page tables. Further, to speed up the process of virtual-to-physical translations, some of these mappings are stored in the TLB, a high speed, limited-capacity cache. Hence, each entry in the TLB essentially provides information about 4KB memory. Figure 1 depicts the addressing scheme for 4KB pages. Figure 2 depicts the contents of a Page Table Entry in 4 level paging scheme.<\/p>\n
Figure 1: Address Translation for 4KB pages<\/p>\n
Figure 2: Structure of PTE at each level of the page table (only relevant fields are shown)
\nTask 1: Lets Print Virtual Memory Mappings [20 Points]
\nIn this task you will implement functionality equivalent to Linux\u2019s \/proc\/[pid]\/maps inside GemOS. Linux\u2019s \/proc\/[pid]\/maps allows users to list virtual memory (VM) layout of a process, for eg: if pid of a process is 1234, open \/proc\/1234\/maps. The VM layout of a process is part of its execution context (Figure 3).
\nFigure 3 shows the execution context (struct exec context) in GemOS (include\/context.h). The execution context points (struct mm segment mms) to different virtual memory segments such as CODE, DATA, STACK etc. The virtual memory areas (vm area) allocated using dynamic memory allocation system call mmap (MMAP) is a list of vm areas and vm area member (struct vm area *vm area) in exec context points to this list as shown in Figure 3.<\/p>\n
Figure 3: GemOS execution context (exec context)
\nImplementation
\n\u2022 The system call and user space library wrapper for kernel function print pmaps(struct exec context *ctx) in mprotect.c is already implemented for you in user\/lib.c. pmaps()
\nis the user space library wrapper and it triggers print pmaps in kernel. You can call pmaps() from user space i.e. from \/user\/init.c.
\n\u2022 You need to complete print pmaps(struct exec context *ctx) kernel function implementation in mprotect.c file, where ctx points to the execution ccontext of the process that made the pmap() system call, using which you can access it\u2019s VM layout.
\n\u2022 The output should be printed in a format start end permissions name
\nwhere start, end corresponds to starting, ending address of VM area, permissions corresponds to read (R), write (W), execute (X) permissions of the VM area (mention \u2013 for any missing permission) and name corresponds to one of these CODE, RODATA, DATA, MMAP, STACK based on VM area. An example of output format is illustrated below.
\n0x100000000 0x100008000 R-X CODE
\n0x180000000 0x180001000 R-X DATA
\n0x180200000 0x180201000 R-X MMAP
\n0x180201000 0x180202000 -W- MMAP
\n0x7FFFFE000 0x800000000 RW- STACK
\n\u2022 The access flags field of struct mm segment and struct vm area in include\/context.h contains permissions information of respective virtual memory layouts.
\n\u2022 Sample test cases are provided in \/user\/testcases\/task1. You need to copy test case file to \/user\/init.c before compiling gemOS.kernel using make in gemOS\/src folder.
\nTask 2: Page Table Manipulations [40 marks]
\nThis part of the assignment, when implemented correctly, will enable lazy allocation support in gemOS. As discussed in class, lazy allocation delays the physical memory allocation corresponding to a virtual address till the virtual address gets accessed (i.e., read or write operation is performed on that address) for the first time.
\nlong vm area pagefault(struct exec context *current, u64 addr, int error code)
\ncurrent: exec context of the process whose execution resulted in the page fault address: Accessed virtual address that resulted in the page fault error code: Provides the information about the fault such as whether the fault occurred in userspace execution or kernel mode execution, type of access i.e, read or write etc. The error codes for various faults are explained in Section 1.
\nDescription: We have provided a template function vm area pagefault() (in src\/mprotect.c) which gets called when a page fault occurs for an address in [MMAP AREA START, MMAP AREA END] (defined in include\/mmap.h). When this page fault handler is called, you have to iterate through the list of VMAs of the process (whose exec context is passed as an argument to this function) to check validity of the address. In the validity checks, verify the faulting address belongs to some VMA and the access matches with the protection flags of the VMA. The following scenarios should be handled by the page fault handler.
\n\u2022 Page fault can arise due to read (error code = 0x4) or write (error code = 0x6) access to an address such that a VMA exists corresponding to the accessed address and no physical page is mapped. Note that write access on an address such that VMA corresponding the address has only read permission should be flagged as an invalid access. All other combinations of accesses and VMA protection flags are considered as valid accesses. For example, read access on an address such that VMA corresponding the address has only write permission is a valid access. For a valid access, you need to do the following,
\n\u2013 Allocate a new physical page frame (PFN), set access flags and update the page table entry(s) of the faulting address. Note that pgd member of a process\u2019s exec context can be used to find the virtual address of the PGD level of the page table using osmap(ctx- pgd).
\n\u2013 You have to structure the PTE entry(s) (Figure 2) at different levels depending on the access flags of the virtual address that is being mapped.
\n\u2022 A page fault can arise due to a read\/write access such that no VMA exists corresponding the accessed address. Such an access should be handled as an invalid access.
\n\u2022 A page fault arising due to a write access to a page marked as READ ONLY (error code = 0x7). In this case, if VMA corresponding the page fault address does not have write permission, flag this access as invalid.
\nReturn Value After fixing fault for a valid access, return 1. For an invalid access return -1.
\nNotes – essay service –
\n\u2022 The pgd of exec context contains the PFN of the PGD level in the page table for the process.
\n\u2022 You can assume that fork()\/vfork()\/cfork()\/clone() will not be called in the test-cases for this part of the assignment.
\n\u2022 You are free to create your own helper functions in gemOS\/src\/mprotect.c
\nTesting
\nThe user space program code is available in gemOS\/src\/user\/init.c. You need to write your test cases in init.c to validate your implementation. The sample test cases in user\/testcases\/task2 can be copied into init.c to make use of them.
\nTask 3: Change Virtual Memory Area Protection [40 marks]
\nIn this task, you need to implement mprotect. The mprotect() system call changes the access protections for the calling process\u2019s memory pages containing any part of the address range in the interval [addr, addr+length-1].
\nint mprotect(void *addr, int length, int prot)
\naddr: The addr argument specifies the start address of the memory mapped region whose protection needs to be changed. You can assume that it will be page aligned.
\nlength: The length argument specifies the length of the mapping (starting from addr) whose protection flags needs to be changed. It will be greater than 0 and need not be a multiple of page size. Length is in bytes.
\nprot: The prot argument describes the desired memory protection of the mapping. It can be one of the following flags:
\n\u2022 PROT READ – The protection of the mapping vm area is set to read only. The physical pages which map to this vm area are also set to read only. Any attempt to write to pages with read only permission results in SIGSEGV.
\n\u2022 PROT READ | PROT WRITE – The protection of the mapping vm area is set to both read and write. Physical pages corresponding this vm area, will have both read and write access.
\nSystem call handler: To implement mprotect() system call, you are required to provide implementation for the template function long vm area mprotect(struct exec context *current, u64 addr, int length, int prot) (in src\/mprotect.c). Note that the system call handler is passed one extra argument (the exec context of the current process).
\nDescription:
\nYou can assume that mprotect() will be used to change the access protection of VMAs only. Based on the arguments passed to the mprotect(), you have to iterate through the list of VMAs of the current process and modify the access permissions. mprotect might create (an existing VMA might be partitioned into multiple VMA\u2019s), expand (after change in protections, a VMA might get merged with adjacent VMAs) or shrink (an existing VMA might be partitioned into multiple VMAs) the vm area mapping. Refer Figure 4. Changing the protection of even a single byte of a page changes the protection of the entire page. It is not an error if the region whose protections need to be changed doesn\u2019t contain any VMAs.<\/p>\n
Figure 4: Impact of mprotect on VMA\u2019s (assume PROT WRITE means PROT READ|PROT WRITE)
\nWhen protections of a virtual address region is changed using mprotect, you should update the virtual to physical translation in page table to enforce the change in access permissions.
\nReturn Value On success, return 0. On failure, return -1.
\nNotes – essay service –
\n\u2022 The address range for will always be between MMAP AREA START – MMAP AREA END. \u2022 You can assume that the dummy node (inserted at the head of the VMA\u2019s list by default) will never be included in the address range specified by mprotect().
\n\u2022 You can assume that fork()\/vfork()\/cfork()\/clone() will not be called in the test-cases for this part of the assignment.
\n\u2022 You are free to create your own helper functions in gemOS\/src\/mprotect.c
\n\u2022 You have to check the validity of arguments (such as prot, length) passed to mprotect().
\n\u2022 You can assume that, maximum number of VMAs at any point of time will be 128 including the dummy vm area.
\nTesting
\nThe user space program code is available in gemOS\/src\/user\/init.c. You need to write your test cases in init.c to validate your implementation. The sample test cases in user\/testcases\/task3 can be copied into init.c to make use of them.
\n1 Utilities
\nIn order to make things easier, we have given some template functions, structures and a few utility functions that facilitate object creation and deletion. Let\u2019s have look at those functions.
\nThe process control block (PCB) is implemented using a structure named exec context defined in src\/include\/context.h. One of the important members of exec context for this assignment is the structure vm area.
\nstruct vm area
\nvm start – The starting address (virtual address) of the vm area mappings. vm end – The ending address (virtual address) of the vm area mappings. access flags – The protection or access flags of the current vm area mappings. vm next – The pointer to the next vm area mappings.
\nMMAP AREA START & MMAP AREA END
\nThese are constants defined in the file gemOS\/src\/include\/mmap.h which is used to specify the overall start and end limit of the mmap space. All the mappings (vm area) which are created using the mmap syscalls will reside within this limit.
\nvoid *os alloc(u32 size)
\nAllocates a memory region of size bytes. Note that you can not use this function to allocate regions of size greater than 2048 bytes. This function returns 0 in case of error. Example usage: struct vm area *vm = os alloc(sizeof(struct vm area)); void os free(void *ptr to free, u32 size)
\nUse os free function to free the memory allocated using os alloc. Example usage: os free(vm, sizeof(struct vm area)); int memcpy(char *dest, char *src, u32 size)
\nThis function copies size bytes from src address to dest address.
\nvoid *osmap(u64 pfn)
\nGiven a page frame number, it returns a virtual address corresponding the passed page frame number.
\nu32 os pfn alloc(u32 region)
\nThis function allocates a new frame in the specified region.
\nTo allocate a frame that is to be used to store page table content, use region = OS PT REG.
\nTo allocate a frame that is to be used to store normal data content, use region = USER REG.
\nu32 os pfn free(u32 region, u64 pfn)
\nThis function frees a page frame given the page frame number and the region to which it belongs to.
\ns8 get pfn(u32 pfn)
\nIncrements the reference count of a frame by one.
\ns8 put pfn(u32 pfn)
\nDecrements the reference count of a frame by one.
\ns8 get pfn refcount(u32 pfn)
\nGet reference count of a frame.
\nstruct exec context* get current ctx(void)
\nThis function returns the exec context of the current running process.
\nPage-Fault Error Code
\nThe error codes generated in case of a page fault are shown in Figure 5, which is taken from course slides. Example interpretation of some of the error codes is as following:
\n0x4 – User-mode read access to an unmapped page
\n0x6 – User-mode write access to an unmapped page
\n0x7 – User mode write access to read-only page
\nFor this assignment, you need to only worry about P, W, U bits.<\/p>\n
Figure 5: Page-Fault Error Codes
\n2 Submission
\n\u2022 Do not have any additional logging\/printing in the submitted code.
\n\u2022 You have to include a file named \u2018declaration\u2019 in your submission. In the \u2018declaration\u2019 file, you have add the following statement:
\n\u201cI have read the CSE department\u2019s anti-cheating policy available at https:\/\/www. cse.iitk.ac.in\/pages\/AntiCheatingPolicy.html. I understand that plagiarism is a severe offense. I have solved this assignment myself without indulging in any plagiarism. If my submission is found to be plagiarized from the internet, fellow students, etc., then strict action can be taken against me. Your Name and Roll No \u201d
\n\u2022 In the \u2018declaration\u2019 file, you also have to mention the resources, such as websites, open source content you referred to while solving this assignment.
\n\u2022 You have to submit zip file named your roll number.zip (for example: 1211405.zip) containing only the following files in specified folder format:
\nyour_roll_number.zip
\n|
\n|—– your_roll_number
\n|
\n|—- mprotect.c
\n|—- declaration
\n\u2022 If your submission is not as per the above instructions, a penalty of 20 marks will be applied on the marks obtained in this assignment.
\n\u2022 Note: No code changes will be allowed after the assignment submission period has ended. So, test your implementation thoroughly with the provided test cases as well as your custom test case<\/p>\n
Operating System Memory Management: A Comprehensive Guide<\/p>\n
Memory management is a crucial aspect of modern operating systems, ensuring efficient utilization and allocation of system resources. This comprehensive guide delves into the intricate details of memory management concepts and their practical implementation within operating system kernels.<\/p>\n
Virtual Memory Mapping and Process Layout
\nVirtual memory mapping is a fundamental concept in operating systems, allowing processes to access a larger address space than physically available memory. Each process maintains a virtual address space, divided into various segments such as code, data, heap, and stack. The operating system kernel is responsible for managing and mapping these virtual addresses to physical memory frames (Silberschatz et al., 2018).<\/p>\n
Page Fault Handling and Lazy Allocation
\nPage faults occur when a process attempts to access a virtual address that is not currently mapped to physical memory. In modern operating systems, page fault handling is a crucial mechanism that enables lazy allocation of physical memory pages. When a page fault occurs, the kernel can allocate a new physical page frame, update the page table entries, and resume the process execution seamlessly (Tanenbaum and Bos, 2015).<\/p>\n
Memory Protection and Access Permissions
\nOperating systems provide mechanisms to control access permissions for memory regions, ensuring data integrity and security. The mprotect system call allows processes to modify the access permissions (read, write, execute) for specific virtual memory areas. This functionality is essential for implementing memory protection schemes, preventing unauthorized access or modifications (McDougall and Mauro, 2017).<\/p>\n
Implementation Considerations
\nImplementing memory management functionality within an operating system kernel requires careful consideration of various factors, such as:<\/p>\n
Virtual Address Space Layout: Defining the appropriate layout for code, data, heap, and stack segments, ensuring optimal utilization and preventing overlaps.
\nPage Table Management: Efficient data structures and algorithms for managing multi-level page tables, handling page faults, and updating translation entries.
\nPhysical Memory Allocation: Strategies for allocating and deallocating physical memory frames, ensuring fair and efficient resource utilization.
\nSecurity and Access Control: Robust mechanisms for enforcing access permissions, preventing unauthorized memory access, and handling potential security vulnerabilities.
\nScholarly References:<\/p>\n
Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating system concepts (10th ed.). John Wiley & Sons, Inc.
\nTanenbaum, A. S., & Bos, H. (2015). Modern operating systems (4th ed.). Pearson Education, Inc.
\nMcDougall, R., & Mauro, J. (2017). Solaris internals: Core kernel architecture (2nd ed.). Prentice-Hall, Inc.
\nLove, R. (2015). Linux kernel development (3rd ed.). Addison-Wesley Professional.
\nGorman, M. (2020). Understanding the Linux virtual memory manager. Prentice-Hall, Inc.<\/p>\n","protected":false},"excerpt":{"rendered":"
Programming Assignment 2 (GemOS Kernel Programming) CS962: Operating System Principles 2023-24 Q3 eMasters in Cyber Security Department of Computer Science and Engineering Due Date: 06th\u2026<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3346,2127,5872,5018,358,5794],"tags":[5871],"class_list":["post-17082","post","type-post","status-publish","format-standard","hentry","category-ae","category-computer-and-information-assignment-help","category-computer-science-and-engineering","category-computer-science-asssignment","category-it-computer-science-assignment-help","category-sa","tag-cs962-operating-system-principles-cyber-security"],"_links":{"self":[{"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/posts\/17082","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/comments?post=17082"}],"version-history":[{"count":1,"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/posts\/17082\/revisions"}],"predecessor-version":[{"id":17085,"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/posts\/17082\/revisions\/17085"}],"wp:attachment":[{"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/media?parent=17082"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/categories?post=17082"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.colapapers.com\/uk\/wp-json\/wp\/v2\/tags?post=17082"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}