The xv6 address space is currently set up like this: In this part of the xv6 pro
ID: 3779758 • Letter: T
Question
The xv6 address space is currently set up like this:
In this part of the xv6 project, you'll rearrange the address space to look more like Linux:
This will take a little work on your part. First, you'll have to figure out where xv6 allocates and initializes the user stack; then, you'll have to figure out how to change that to use a page at the high-end of the xv6 user address space, instead of one between the code and heap.
Some tricky parts: one thing you'll have to be very careful with is how xv6 currently tracks the size of a process's address space (currently with the sz field in the proc struct). There are a number of places in the code where this is used (e.g., to check whether an argument passed into the kernel is valid; to copy the address space). We recommend keeping this field to track the size of the code and heap, but doing some other accounting to track the stack, and changing all relevant code (i.e., that used to deal with sz ) to now work with your new accounting.
You should also be wary of growing your heap and overwriting your stack. In fact, you should always leave an unallocated (invalid) page between the stack and heap.
The high end of the xv6 user address space is 640KB (see the USERTOP value defined in the xv6 code). Thus your stack page should live at 636KB-640KB.
One final part of this project, which is challenging: automatically growing the stack backwards when needed. Doing so would require you to see if a fault occurred on the page above the stack and then, instead of killing the offending process, allocating a new page, mapping it into the address space, and continuing to run.
Explanation / Answer
1. The exec system call currently has this signature:
Introduce a new system call named new_exec such that the second argument indicates the maximum size of the stack (in number of pages)
The stack should still be growing (you shouldn't statically allocate it), but if this parameter is set to a non-zero value, and the stack tries to grow beyond this point, you should kill the process.
Note that this only applies to processes using new_exec: existing code using exec is unaffected.
Currently, the heap starts right after the code page. Modify this so that there is an unmapped guard page between the code and the heap. The structure should look like this:
You should be able to demonstrate what happens when user code tries to access a null pointer. If you do this part correctly, xv6 should trap and kill the process without too much trouble on your part.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.