-
Notifications
You must be signed in to change notification settings - Fork 0
/
lab2-questionary.txt
125 lines (121 loc) · 6.79 KB
/
lab2-questionary.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
=== This template file contains questions you need to answer.
=== Fill your answers on appropriate blank lines only.
=== Don't start any line with three equal signs "===".
=== Don't edit any lines starting from three equal signs.
=== Use C notation to write numbers: 42 for decimal, 0x2a for hexadecimal.
=== We may check most of the answers automatically, so "forty two" or
=== "26+16" won't work for this example. Spaces are mostly ignored, so
=== " 42 " is OK (without quotes of course).
=== When asked to specify address & instruction, do it in the form of
=== gdb output "ADDRESS: INSTRUCTION", for example "0x7c26: or $0x1,%eax"
=== Don't make lines longer than 80 characters. You don't need to fit your
=== answer in a single line, you can start a new line at will.
=== However, when asked to fill "a table" make each table raw a single line.
=== Q What's the purpose of leaving virtual memory region
=== 0xeebfe000-0xeebff000 inaccessible?
=== (free form, up to 10 words)
To prevent User Exception Stack from overwrite User Noraml Stack
=== Q Define a page table entry with the following properties:
=== frame starts at 0x1234000. It can be written by the kernel
=== without causing any errors, but has never been written yet. On
=== the other hand, application cannot write to the page, but has
=== recently successfully read from it. All bits which are not
=== responsible for above properties are set to zero.
=== (a single memory WORD as would be output by gdb's x/1x)
0x1234025
=== Q Consider JOS kernel code:
=== mystery_t x;
=== char* value = return_a_pointer();
=== *value = 10;
=== x = (mystery_t) value;
=== What type mystery_t should refer to?
=== (remove leading "====" from the correct answer line)
uintptr_t
==== physaddr_t
=== Q What information is stored in page directory when mem_init()
=== finishes? For each non-empty PD entry specify:
=== - decimal index (0-1023)
=== - hexadecimal address of virtual memory mapped by this entry
=== - name of kernel data structure which is intended to be
=== accessible through this PDE (when appropriate, in quotes)
=== - general name (free form, up to 10 words in quotes)
=== Sort the table by the index in ascending order. If several
=== consequent entries are only differ in address field, you can
=== specify ellipses ("...") instead of an "inner" entries. Please
=== align columns into readable table using spaces.
=== Format example (all the values are made up; omit the header):
=== INDEX ADDRESS DATA-STRUCTURE NAME/DESCRIPTION
=== 24 0x12345 "struct Segdesc gdt[]" "Global descriptor table"
=== ...
=== 42 0x98765 "struct Segdesc gdt[]" "Global descriptor table"
=== 50 0x00011 "" "boot loader code"
956 0xef000000 "struct PageInfo* pages" "User pages"
957 0xef400000 "volatile pte_t uvpt[]" "Current page table (User)"
958 0xef800000 "char bootstack[]" "Kernel stack"
959 0xefc00000 "pde_t *kern_pgdir" "Current page table (Kernel))"
960 0xf0000000 "" "Page table for bottom 4MB of physicals memory"
..............
1023 0x0ffc0000
=== Q We have placed the kernel and user environment in the same
=== address space. Why will user programs not be able to read or
=== write the kernel's memory? What specific mechanisms protect the
=== kernel memory?
=== (free form, up to 15 words)
There are different mapping with different permissions, for user and kernel
=== Q Which virtual addresses are readable by the user?
=== (in the form ADDR1-ADDR2, if none, specify NONE)
0x00800000-0xeebfe000, 0xeebff000-0xef800000
=== Q Which virtual addresses are writable by the user?
=== (in the form ADDR1-ADDR2, if none, specify NONE)
0x00800000-0xeebfe000, 0xeebff000-0xeec00000
=== Q Assume a hacker can change N bits inside page table (on any
=== level, PD or PT) after it has been set up by the kernel (and
=== before full TLB flush). What is the minimal N to gain full
=== control of the system from hacker's user space process?
2
=== Q What's the maximum amount of physical memory this kernel can
=== support? (number of megabytes, without MB suffix)
256
=== Q What single constant can be changed in kernel source to make
=== this limit 2 times lower (if kernel normally supports 10MB,
=== we want to make it support only 5MB?
KERNBASE
=== Q What value should this constant be changed to?
0xf8000000
=== Q Assume the computer has the maximum amount of memory supported
=== by the (unmodified) kernel. What's the overhead of managing this
=== memory in terms of (physical) memory spent?
=== Specify only data structures which size depends on the amount of
=== physical memory and exclude the "fixed" overhead. For example,
=== if data structure size is 123K+0.01*(memory size) and maximum
=== amount of memory is 100MB, specify 0.01*100MB = 1024KB.
=== For each such data structure specify:
=== - size in KB (without "KB suffix")
=== - name of kernel data structure (when appropriate, in quotes)
=== - general name (free form, up to 10 words in quotes)
=== Sort the table by the size in ascending order. Please
=== align columns into readable table using spaces.
=== Format example (all the values are made up; omit the header):
=== SIZE DATA-STRUCTURE NAME/DESCRIPTION
=== 42 "struct Segdesc gdt[]" "Global descriptor table"
512 "struct PageInfo* page" "PageInfo array"
256 "volatile pte_t uvpt[]" "Page Table"
4 "volatile pde_t uvpd[]" "Page Directory"
====================================================================
=== Q What challenge(s) have you chosen to implement? (specify
=== challenge numbers separated by spaces, if more than one)
2
=== Q If the challenge requires changing the kernel source, list the
=== files which you have changed/added during implementation.
=== (one file per line, relative to lab directory containing .git/)
kern/monitor.h
kern/monitor.c
=== Q Describe your solution.
=== (free form, up to 500 words, don't need to use all 500!)
We have written 4 functions for this challenge: showmaps, setprems, vadump (dump by VA) and padump (dump by PA).
For each function we've check the arguments.
showmaps: retrieve the PTE with 'pgdir_walk', and from it takes the permissions and physical address, to print them nicely.
setprems: again, for each given address, use 'pgdir_walk' to retrieve PTE - and change the permissions bits according to the given ones.
vadump: for each VA in range, retrieves the PTE, and from it the page. adds to it the offset of the VA, so reading through different pages goes smoothly.
then prints the content of the formatted address nicely - if flag is turned on, prints every 4 bytes, if not -every byte.
padump: for each PA in range, simply prints the direfferenced(after adding KERNBASE) content nicely. same flag like vadump.