-
Notifications
You must be signed in to change notification settings - Fork 0
/
lab2-questionary.txt
executable file
·166 lines (139 loc) · 7.39 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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
=== 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 stack from overflowing and corrupting data.
=== 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"
0 0x00000000 “base of vm” “”
…
956 0xEF000000 “Pages info array” “pages data structure”
957 0xEF400000 “kernel pgdir” “”
958 0xEF800000 “KSTACK” “kernel stack without guard”
…
960 0xF0000000 “KERNBASE” “the beginning of kernel”
…
1023 0xFFC00000 “END OF KERN” “”
=== 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)
the permission bits in the table entries prevent and allow access to different cpls.
=== Q Which virtual addresses are readable by the user?
=== (in the form ADDR1-ADDR2, if none, specify NONE)
0x00000000-0xef800000
=== Q Which virtual addresses are writable by the user?
=== (in the form ADDR1-ADDR2, if none, specify NONE)
0x00000000-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?
1
=== 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"
4 “pgdir” “page global directory”
256 “pt” “page tables”
512 “pages array” “pages info”
====================================================================
=== Q What challenge(s) have you chosen to implement? (specify
=== challenge numbers separated by spaces, if more than one)
we chose the challenge to extend the JOS kernel monitor commands.
=== 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.c
ker/monitor.h
=== Q Describe your solution.
=== (free form, up to 500 words, don't need to use all 500!)
we implemented 3 main functions in monitor.c file.
first, showmappings - shows the mappings for either a range or a single page including
the permissions in human readable format.
use case for single page is ‘showmappings ADDR’
use case for range format is ‘showmappings ADDR_1 ADDR_2’
the second function is setperm, which overwrite the present permissions to pages.
it also works for either ranges or single page this time using then -r flag.
use case for single page is ‘setperm ADDR PTE_U PTE_W’
use case for range format is ‘setperm -r ADDR1 ADDR2 PTE_U PTE_W’
third function we implemented is dump, which prints the content of the memory in addresses.
it always requires an address range and it will print each word in that range.
it has two flags, -p for physical (only kernel space) and -v for virtual.
use case for physical is ‘dump -p ADDR1 ADDR2’
use case for virtual is ‘dump -v ADDR1 ADDR2’
we added more functions of our own:
1) addrlayout - prints the area in memory which a virtual address resides in:
example: ‘addrlayout 0x0’ will print “Empty Memory”
it can receive several addresses and once.
2)freespace - prints the total amount of free space in memory out of total.
example: ‘freespace’ will print number/number in KB.
3) reftopa - prints the number of references to a given address
example: ‘reftopa 0x0’ will print “the physical address 0x0 has 2 references”
it can receive several addresses and once.