INTRODUCTION

1. As part of this assignment, you will be implementing mprotect system call in gemOS.
2. The gemOS source can be found in the Assignment2/gemOS directory.
3. This source provides the OS source code and the user space process (i.e., init process) code (in Assignment2/gemOS/user directory).

 

 

THE SYSCALL SPECIFICATION

1. The mprotect system call to be implemented is similar to POSIX mprotect
2. The specifications of the system call that you need to implement is as follows:

• int mprotect(void *addr, size t length, int prot) :

mprotect changes the access protections for the calling process's memory pages in the address range (addr, addr+ length-1). 

Assume that addr provided as argument is always page aligned. 

mprotect might create, expand or shrink the vm_area  mapping 

As we are updating the access rights of certain regions in the vm area, the access rights should also be updated accordingly in the underlying page table entry as well if a mapping exists. 

If the calling process tries to access memory in a manner that violates the protections, then the OS generates a SIGSEGV signal for the process. 

The prot argument describes the desired memory protection of the mapping. 

 

 

 

It can be bitwise OR of one or more of the following flags (already defined in the provided template): 

• PROT_READ - The protection of the mapping of the specified range of the virtual address is set to READ ONLY (by modifying the vm area meta-data). The page table mapping for the pages in the area should be set to READ ONLY. If any process tries to write on this physical page, it will result in SIGSEGV .
• PROT_WRITE - The protection of the mapping of the specified range of the virtual address is set to WRITE ONLY (by modifying the vm area meta-data). The page table mapping for the pages in the area should be set to WRITE ONLY. When it comes to physical pages, PROT WRITE implicitly provides read access to physical pages. Hence, the physical pages which map to this vm area will have both READ and WRITE access.

 

RETURN VALUE

• On success, mprotect() returns 0.
• If any part of the provided addr is invalid or the prot argument is invalid, then mprotect will fail and returns -EINVAL

 

BACKGROUND AND UTILITIES 

• The process control block (PCB) is implemented using a structure named exec_context defined in include/context.h.
• One of the important members of exec context for this assignment is the vm area structure.

struct vm area: 

• vm_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.

The vm area pointer from the exec context represents a linked list of all address ranges allocated using the mmapsystem call. 

            This list is modified based on already implemented system calls such as mmap                              and munmap. 

struct vm_area* alloc_vm_area(): 

• This function (in include/mmap.h) is used to create a new vm area mapping and returns a pointer to the created vm area .
• You need to set the values of vm_area fields.
• You should use this function to create vm area in the entire assignment.

void dealloc_vm_area(struct vm area *vm): 

• This function (in include/mmap.h) is used to delete or deallocate the vm area, which is passed as an argument.
• You should use this function to delete or deallocate vm area in this assignment.

MMAP_AREA_START & MMAP_AREA_END:

• These constants defined in the file [include/mmap.h] specify the start and end limit of the mmap address space.
• All mappings created using the mmap syscall resides in this range.

 

static inline void invlpg(void* addr)):

• This function flushes the TLB entry corresponding the address addr.

 

void* osmap(u64 pfn):

• This function return the virtual page address corresponding to a physical page.
• You can use this to convert physical page address to virtual address.

 

Format of the Page Table Entry:

The format of PTE entry which maps to 4KB pages in intel x86-64 architecture is as shown in figure 

 

 

HOW TO SETUP gemOS

1. Please setup the docker container using the instructions provided in the document titled 'Instructions for Running GemOS Docker Instance'. Further instructions below assume that you have a working setup.
2. Running container: Open a terminal in host machine and run the command '$sudo docker ps'. Find the container id. Let the container id be 2d2d13fb1d8d. Run the command '$docker start container-id'. For example, '$docker start 2d2d13fb1d8d'.
3. Login into the container: Login as a user with command '$ssh -p 2020 o..s@localhost'. Password is 'cs330'.
4. Copying files from host machine to container: Open another terminal in host machine . Make the 'Assignment2/gemOS' as your current working directory in this terminal. From 'Assignment2/gemOS' directory run the following command to copy gemOS files from your host machine into the container.

'$scp -P 2020 -r * o..s@localhost:∼/gemOS/src'. 

1. Modifying gemOS kernel: In container terminal, make '/home/osws/gemOS/src' as your current directory. In this directory you have to write your logic for task-1 and task-2 in mprotect.c file.
2. Compiling gemOS kernel: To compile the gemOS kernel after modifications, run $make command in '/home/osws/gemOS/src' directory
3. Running gemOS kernel: To run the gemOS kernel, change the current working directory of container terminal to /home/osws/gem5 and use the command '$./run.sh /home/osws/gemOS/src/gemOS.kernel'
4. Connecting to gemOS console: Open another terminal in host machine. SSH into the container using '$ssh -p 2020 osws@localhost' command. To connect to gemOS console, write the following command in this terminal: '$telnet localhost 3456'
5. Running a process in gemOS: In gemOS console, write the command '$init' to run the userspace 'init' process.
6. Running testcases in gemOS: To run a testcase, copy the testcase file to init.c. For example, '$ cp /home/osws/gemOS/src/user/testcases/task1/testcase4.c /home/osws/gemOS/src/user/init.c'

 

TASK 1: Virtual memory area operations 

• In this task, you are required to provide the implementation for the function vm_area_mprotect in the file [mprotect.c]).
• This function is invoked when mprotect system call is made.
• vm area mprotect takes the current context, address, length, and required protection as arguments.
• If the provided address is not part of any vm_area, then mprotect should fail and return -EINVAL.
• As part of this task, you are expected to modify access protection of the VMA in the range (addr, addr+ length-1) as shown in Figure 1.
• Change in access protections of a VMA can lead to the splitting/ merging of VMAs.

Validation Procedure: 

• In this part of the assignment, we will validate the state of VM area, a singly linked list pointed to by vm_area field in struct exec context in include/context.h.
• We will examine the vm area linked list before and after the mprotect syscall.
• There can be at most 128 vm area at any point of time. If this limit is exceeded, then return -EINVAL.
• If the address range for mprotect system call does not belong to a valid vm area then return -EINVAL.
• Assume all the addresses provided to the mprotect syscall are page-aligned.

 

TASK 2: Updating access rights of physical pages (50 Marks)

• In this task, you need to add additional functionality to the function vm_area_mprotect .
• On changing the access protections of a vm area mapping, you have to modify the access protec- tions of the mapped physical pages of the vm area by walking the page table
• For example, if we change a vm area permission to WRITE ONLY from READ ONLY through a mprotect system call, then you have to modify the relevant page table entries to allow write operation on them.
• Note: pgd value can be found in struct exec context.

 

Validation Procedure: 

• We will change access permissions through mprotect system call and validate read, write access to corresponding vm_area.

Submission guidelines

• You have to submit one file (mprotect.c). Put this file in a directory named with your roll number. Create a zip archive of the directory and upload it. For example: If your roll number is 12111260, then your submitted zip file should have the following structure:

     12111260.zip           |           |----- 12111260                     |----- mprotect.c

• Don't modify any other files. We will not consider any file other than mprotect.c for evaluation.

• You should remove all printk debug statements from submission file. We will take diff between your output and the expected output for evaluation.

• Test your implementation with more test cases. We have provided open test cases in testcases folder.

 

 

I will submit this work as my own
 
 

Address space before operation Changing access rights vm1 1. Region to be changed is at the end of existing vm_area vm1 vm2 vm2 Address space after operation Access rights changed vm1 vm3 The new vm_area is created at the end with new access rights vm1 vm3 vm2 vm2 2. Region to be changed is at the front of existing vm_area The new vm_area is created at the front with new access rights vm1 3. Region to be changed is inside the existing vm_area and has different access rights vm1 vm2 vm3 The new vm_area is created in between the existing vm_area with requested access rights vm1 vm2 4. Region to be changed is at the end of existing vm_area and next contiguous vm_area has same access rights as requested vm1 vm2 The existing vm_area is shortened and the next contiguous vm_area front is extended as it access rights is same as requested PROT_READ PROT_WRITE Figure 1: Performing mprotect() on the VM areas