Answers to 11/1 Survey questions
For the following three questions, assume that in your user-level program (on an x86-64), you have an array whose start address is 0xAFF0 and whose end address is 0xB00F (that is the address of the last byte in the array). The array begins at address 0x5FF0 in physical memory.
1. What do you know about the size of that array (check all that apply)?
It is 32 bytes long: Let's subtract the start address from the end address and add 1 since the end address is the address of the last byte: 0xB00F - 0xAFF0 = 32 (0x20). OK, this one is true!
It is 4096 bytes long: Nope -- we just determined that it's 32 bytes, not 4096.
It must hold integers: Well, the array size is a multiple of 4, so it could hold integers, but it doesn't have to.
It might hold longs: The length is also a multiple of 8, so it could hold longs.
You can't tell anything
2. What do you know about the physical address of the last byte in the array.
It is 0xB00F: No, that's its virtual address.
It is 0x6FF0:This address doesn't even have the right page offset for the last byte, so we know it's not correct, but even if it did, there is no guarantee that two consecutive pages in virtual memory are also consecutive in physical memory, so we don't know this for sure.
Its page offset is FF0: No, the virtual address of the last byte is 0xB00F; the page offset of the virtual address must be the same as the page offset of the physical address, so the page offset of the last byte must be 0x00F.
Its page offset is 32: No, see previous answer.
You don't know anything about the address: Not a great answer: you do know that it has a page offset of 0x00F, but you really don't know anything else.
3. Let's say that the process passes the address of the array as a parameter to the read system call and asks to read 20 bytes. How many calls to virtual_memory_lookup should the kernel make to check the arguments?
The kernel needs to make as many calls as there are pages to touch, so
the question is how many pages might a 20 byte array starting at virtual
address 0xAFF0 touch? Well, there are 16 bytes left on the page whose
virtual page number is 0xA, so a 20 byte array is going to span two
pages, so we would have to call virtual_memory_lookup twice.
4. Virtual memory requires the cooperation of both the hardware and the software. For each item below, indicate whether the functionality requires each of the hardware, the operating system, and the application to do anything. (You can pick multiple items in each row.)
Set of the contents of a page table: The OS is responsible for that.
Make a particular page table the one that will be used for translations: This is a joint effort between the HW and the OS -- the OS decides which page table to make the current one, but it needs the hardware instruction that will actually force the HW to use the table for translations.
Detect that the currently running process is trying to access an address for which it does not have a mapping: This is precisely what the Hardware does on every memory access.
Handle a page fault: The HW gives the operating system control when a page fault happens, but it is the Operating System that is responsible for actually handling the page fault.
Prevent a user process from changing its own page tables: This is another cooperative effort -- the OS sets the protection bits in the PTEs that reference the page tables, but the HW enforces the constraint that prevents a user process from writing to the page tables.
For the following questions, select all the mechanisms that could be used to prevent the evil behavior.
5. A user process hogging the processor (check all that apply).
Having the kernel turn off interrupts: This doesn't really help us here.
Setting timer interrupts: This is exactly what we need -- we need to interrupt a piggy process.
Giving a user process its own pagetable: Doesn't help us here.
Have some instructions that user programs may not execute: This is definitely helpful -- prevents the user process from turning off interrupt!
None of the above
6. A user process turning off interrupts (check all that apply).
Having the kernel turn off interrupts: Well, that doesn't really help us here.
Setting timer interrupts: That doesn't prevent a process from turning off interrupts.
Giving a user process its own pagetable: N either does this!
Have some instructions that user programs may not execute: Aha, here is the solution -- by making the instruction that turns off interrupts privileged, we prevent a user process from turning interrupts off.
None of the above
7. A user process scribbling over the kernel's memory (check all that apply).
Having the kernel direct map all of physical memory in its page table: That doesn't seem to help us here.
Creating a user process's pagetable by copying the kernel's page table: Well, just copying the kernel's page table doesn't help here either.
Not setting PTE_P on kernel pages: That would be a problem -- the kernel's pages definitely need to be present!
Not setting PTE_U on kernel pages: Here's the solution -- if the kernel pages do not have PTE_U set, then the user process cannot access them.
Giving the user a page table without mappings for the kernel: This seems like it could also work, but we'd then have to switch page tables every time we went into the kernel.
8. A user process scribbling over another process's memory (check all that apply).
Having the kernel allocate memory: That doesn't really seem to help us.
Creating a user process's pagetable by copying the kernel's page table: Well, having our own page table is a good start, but the fact that we copy the kernel's doesn't really help us.
Not setting PTE_P on process pages: We certainly do need to set PTE_P on our own pages!
Not setting PTE_U on process pages: And we certainly need PTE_U to access our own pages.
Giving each process its own pagetable: Aha -- but if each process has its own page table, then we can prevent processes from scribbling on each other's memory!