This assignment must be done on a Ubuntu Operating System.

Youtube link - https://www.youtube.com/watch?v=M2CPjjVTmpg

You can find the xv6 file here - https://drive.google.com/file/d/1cGT8ZuQ8LQsWWc2VxTOis-fFRnqY2TkI/view?usp=sharing

Part A: Null-pointer Dereference The following video is very useful to better understand PART A of the project Video 1 About the project; https://www.youtube.com/watch?v M2CPiiVTmpg In xv6, the VM system uses a simple two-level page table as discussed in class. As it currently is structured, user code is loaded into the very first part of the address space Thus, if you dereference a null pointer, you will not see an exception (as you might expect); rather, you will see whatever code is the first bit of code in the program that is running. Try it and see! Thus, the first thing you might do is create a program that dereferences a null pointer It is simple! See if you can do it. Then run it on Linux as well as xv6, to see the difference Your job here will be to figure out how xv6 sets up a page table. Thus, once again, this project is mostly about understanding the code, and not writing very much. Look at how execo works to better understand how address spaces get filled with code and in general initialized. That will get you most of the way. You should also look at forko , in particular the part where the address space of the child is created by copying the address space of the parent. What needs to change in there? The rest of your task will be completed by looking through the code to figure out where there are checks or assumptions made about the address space. Think about what happens when you pass a parameter into the kernel, for example; if passing a pointer, the kernel needs to be very careful with it, to ensure you haven't passed it a bad pointer How does it do this now? Does this code need to change in order to work in your new version of xv6? One last hint: you'lI have to look at the xv6 makefile as well. In there user programs are compiled so as to set their entry point (where the first instruction is) to 0. If you change xv6 to make the first page invalid, clearly the entry point will have to be somewhere else (e.g., the next page, or 0x1000). Thus, something in the makefile will need to change to reflect this as well You should be able to demonstrate what happens when user code tries to access a null pointer. When this happens, xv6 should trap and kill the process. The good news: this will happen without too much trouble on your part, if you do the project in a sensible way, because xv6 already catches illegal memory accesses. Part A: Null-pointer Dereference The following video is very useful to better understand PART A of the project Video 1 About the project; https://www.youtube.com/watch?v M2CPiiVTmpg In xv6, the VM system uses a simple two-level page table as discussed in class. As it currently is structured, user code is loaded into the very first part of the address space Thus, if you dereference a null pointer, you will not see an exception (as you might expect); rather, you will see whatever code is the first bit of code in the program that is running. Try it and see! Thus, the first thing you might do is create a program that dereferences a null pointer It is simple! See if you can do it. Then run it on Linux as well as xv6, to see the difference Your job here will be to figure out how xv6 sets up a page table. Thus, once again, this project is mostly about understanding the code, and not writing very much. Look at how execo works to better understand how address spaces get filled with code and in general initialized. That will get you most of the way. You should also look at forko , in particular the part where the address space of the child is created by copying the address space of the parent. What needs to change in there? The rest of your task will be completed by looking through the code to figure out where there are checks or assumptions made about the address space. Think about what happens when you pass a parameter into the kernel, for example; if passing a pointer, the kernel needs to be very careful with it, to ensure you haven't passed it a bad pointer How does it do this now? Does this code need to change in order to work in your new version of xv6? One last hint: you'lI have to look at the xv6 makefile as well. In there user programs are compiled so as to set their entry point (where the first instruction is) to 0. If you change xv6 to make the first page invalid, clearly the entry point will have to be somewhere else (e.g., the next page, or 0x1000). Thus, something in the makefile will need to change to reflect this as well You should be able to demonstrate what happens when user code tries to access a null pointer. When this happens, xv6 should trap and kill the process. The good news: this will happen without too much trouble on your part, if you do the project in a sensible way, because xv6 already catches illegal memory accesses