Last updated: March 29, 2021
Carleton University School of Computer Science
COMP 3000 (WINTER 2021) OPERATING SYSTEMS TUTORIAL 8
Tasks part A: Getting Started
Compile and using the provided Makefile (i.e., by running make). Insert by running . Confirm that the module is inserted using lsmod.
3000physicalview
3000memview2
3000physicalview
make insert
1. Examinethecallto andcopy_to_user()onlines120and132 of . Consider the following:
3000physicalview.c
copy_from_user()
o How are these functions different from that we have seen in the previous tutorial?
is comparable to memcpy() which deals with a range of memory, whereas is used for single variables (e.g., a char or
int).
o Why are these functions necessary? Couldn’t we just access the userspace address directly? What could happen if we did?
If you try to use memcpy() to replace these four functions it *may* work. However, losing fault containment as part of the price for running code in kernelspace, any invalid addresses passed in to the kernel module (e.g., null, or pointers to other processes or even the kernel¡¯s memory) will lead to kernel oops or even panic. These four functions do all the access checks and ensure that the addresses are valid.
get_user()/put_user()
copy_from_user()/copy_to_user()
get_user()/put_user()
2.
exposes its API to userspace in the form of an call. Consider the
3000physicalview
following:
ioctl(2)
o What is an ioctl? How is it different from a read or write system call? Hint: check man 2 ioctl.
In addition to the differences in syntax, consider ioctl() and read/write() in two aspects: read and write are natural operations to a file, also applicable to special files. If they are called in-band, we can call ioctl an out-of-band channel, which can adjust the behavior of regular reads/writes. On the other hand, read() is one-way only for reading and write() is one-way only for writing. ioctl() is two-way: you can provide input and get output to fulfill any tasks.
o How does
In in
to the device), a command (
data structure (one member being the virtual address and the other being the returned physical address).
3000physicalview
implement its ioctl? What arguments does it take?
, ioctl takes a file descriptor (referring
physicalview_ioctl()
3000physicalview.c
PHYSICALVIEW_WALK
o How does call the ioctl? What arguments does it pass to the ioctl? Looking at the call to in , the arguments passed in correspond to the three above. In particular, is defined in 3000physicalview.h. For now, just treat it as a value agreed on by both the driver and the application to
3000memview2
), and an address pointing to a custom
ioctl()
3000memview2.c
PHYSICALVIEW_WALK
perform this translation.
3. Which function does the virtual-to-physical translation? What type is ? How does it give you the address of the pgd? Recall the page table walk explained in Lecture 17 and see how it¡¯s reflected in this function (writing it down is optional).
.
. Here you see how page tables can be per-process.
contains a member pointer: pgd_t * pgd, pointing to its pgd.
Each takes the address of its parent-level table, and returns an address to an p?? entry corresponding to a given virtual address, all the way down to a pte.
4. Once you¡¯ve got the page frame number (pfn), how is the physical address (phys) calculated? Describe in words.
The page frame number is retrieved from the pte in the last-level page table, referring to a
get_physical()
struct mm_struct
mm_struct
p??_offset()
current->mm
physical page frame but not the page frame address yet. For example, if the number is 0x1234, the address should be 0x1234000 (as the page size is 4KiB, taking 12 bits = 3 nibbles). Therefore, to get the translated physical address, we use the page frame start address (0x1234 shifted to the left by 12 bits = 0x1234000) + the offset within the page frame (extracting the last 12 bits from addr).
Tasks part B: Examining Physical Memory Mappings
1. With inserted, run and examine the output. Note that it presents virtual memory addresses on the left, and physical addresses on the right. Are these mappings consistent with what you expected (e.g., in terms of patterns)?
The virtual addresses on the left demonstrates the layout of a typical memory space (as mentioned in Tutorial 3), while the physical addresses on the right show no patterns overall.
2. Compare3000memview2with3000memviewfromTutorial3.Whatissimilarabouttheircode,and what is different? How similar is their output?
They both define various types of variables and print their addresses. uses printf() on their virtual addresses while 3000memview2 uses the driver to report their physical addresses as well as the virtual ones.
3. Doyounoticeapatterninthevirtualaddressesofbuf[i]?Isthissamepatternpresentinthe physical addresses? Why or why not?
If you look at the last three nibbles (e.g., 6b0) of the addresses of buf[i], you¡¯ll see they are incrementing (continuous) and the same is seen in both virtual and physical addresses. This shows that memory is managed (allocated) in pages. No matter how the mapping is done (maybe not as you expected), the granularity is page.
3000physicalview
3000memview2
3000memview
3000physicalview
4. Run
3000memview2
a few more times and consider the following:
o Are the virtual addresses the same or different between runs? How about physical addresses? In general, all (both virtual and physical) addresses are changing. ASLR contributes to the change of virtual addresses, and the kernel just allocates/deallocates memory pages affected by many factors not pertaining to the process in question hence the change of physical addresses.
o Some physical addresses don’t seem to be changing between runs. Which ones? Why do you think this might be the case?
2
main, lmsg and gmsg. See below.
5. Forcethekerneltodropthevirtualmemorycacheusing
/proc/sys/vm/drop_caches. Run 3000memview2 one more time and note that the physical addresses that stayed the same previously have now changed. What do you think just happened? What is cached and what is not:
Recall that the page cache is actually ¡°disk cache¡± which stores recently accessed data from block devices, including files. Then it¡¯s about which part of the address space is from files and which is not. Checking the memory layout (e.g., using pmap) you can see the program binary and various dynamic libraries are from files, while the rest is not, e.g., stack, heap, bss, etc. Among the variables of 3000memview2, only lmsg and gmsg (in the data segment) and main (in the text/code segment) are from the program binary file 3000memview2, hence cached.
sync && echo 3 | sudo tee
3