This repository has been archived by the owner on Nov 15, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathISSUES
172 lines (108 loc) · 6.04 KB
/
ISSUES
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
166
167
168
169
170
171
172
The following are known issues. Please help resolve these issues. Thanks in
advance for your patch.
-Ultravisor Team
----------------------------------------------------------------------------------
System Power Down:
On reboot, hostboot firmware is responsible for clearing all memory,
thus not exposing any stale information residing in memory. This is to
defend against any attacks, that read the content of the secure memory
on reboot. The ultravisor can further strengthen the defence, by
zeroing secure memory before shuting down. Explore this approach.
ESM blob attached to zImage:
Ultravisor is currently unable to handle ESM blob that is attached to
the zImage. Fix this.
Store ultravisor logs on the host:
The ultravisor log is a circular buffer that overwrites its content on
overflow. This is same as the Linux kernel's dmesg log. Enhance the kernel
to provide the same functionality as dmesg, where the ultravisor log
is regularly stored in the hosts' filesystem.
Prune SVM device tree:
The device tree for a VM is generated by the Hypervisor. However Ultravisor
must not allow VM's that contain insecure objects/properties in the device
tree, to turn secure. Prune such objects/properties, before switching the
VM to secure VM.
RTAS tokens:
Ultravisor stores the token value of each RTAS call in a global linked list.
This token value is a property of QEMU instance, and can vary between SVMs.
A malicious QEMU can change the values of the RTAS token and modify the
behavior of a SVM that innocently assumes traditional values of RTAS token.
Make the token values local to SVM to close this vulnerability.
Fine grained error values, when UV_ESM fails.
UV_ESM ultracall can fail for various reasons. When it fails the VM is
terminated with a generic message that it failed. It does not provide any
further details towards the cause. The administrator can refer the
ultravisor logs to determine the reason for the failure. However providing
QEMU with the exact reason for the failure, can enable better servicability.
RTAS code check:
The RTAS code running in the VM is donated by the hypervisor.
Ultravisor must ensure that a well known version of the RTAS code is
loaded. This solution works since the RTAS code is never expected to
change in the near future. However this solution is inflexible since
it does not allow for any new RTAS version. Enhance the Ultravisor to
load its own trusted version of RTAS into the SVM's memory. This
solution has two advantages. It does not rely on untrusted software to
provide RTAS code. It also provides the ability to enhance the RTAS
software in the future.
Ultravisor Heap:
The ultravisor heap is statically configured and its size is not
proportionate to the size of the secure-memory. When more secure-memory
is configured, the demand for memory in the ultravisor heap increases.
The current implementation fails to scale. Modify the ultravisor heap
size to be proportionate to the amount of secure memory available in
the system.
libfdt:
The code is dependent on a much older version of libfdt. Update it to a
newer version.
Ucall error code:
The ultravisor ucall API attempts to map error codes to the
corresponding hypervisor API's error code wherever possible. Eg U_INVAL
is defined as H_INVAL. This inhibits the ultravisor to define its own
new error codes. Relax this restriction, and rework the error codes,
without breaking any current users.
Ultravisor log timestamps:
The ultravisor logs do not correctly capture timestamps that follow the
chronological order. This is because the ultravisor does not have a good
timebase to rely upon. Explore a good that can overcome this problem.
Ultravisor statistics:
The ultravisor does not expose any statistics towards the amount of secure
memory currently available, currently used, number of secure VMs currently
running and other details that an administrator expects. There is a downside
of exposing too much information without hurting security of the system.
However not having necessary and sufficient information also has its downsides.
Address this issue.
SMFCTRL(D):
The SMFCTRL(D) flag when unset, lets lesser privileged software to use
the debug registers on the CPU. This inhibits the ultravisor from using
the debug registers. If in case, in the future if ultravisor decides to
use these registers, this flag must be enabled. Also the ultravisor
must ensure that the values in the debug register are normalized before
disabling the flag.
Fix Stack frame bloat:
Some fields of the stack frame are not used. They can potentially be
deleted. Consider dropping lpid, pidr, lpcr fields.
Procure Secrets from the ESM blob: (HIGH Priority)
UV_ESMB_GET_FILE ultracall fails after about 125 invocations. The
failure, sometimes hangs the ultravisor, inturn hanging the entire
system. This is a easy denial-of-service attak. Fix this ASAP.
Check for non-virtio based PCI devices: (HIGH Priority)
If a VM containing non-virtio PCI devices tries to switch to a secure-VM,
the system can checkstop. Fix this ASAP.
XIVE Support:
XIVE when enabled in the Secure VM, will expose a new memory slot.
This memory slot must be treated specially. All the pages in the slot
must be shared with the hypervisor. Figure out the details and
implement it accordingly.
Validate Hypervisor page:
Hypervisor provides a page as a parameter for UV_PAGE_IN and
UV_PAGE_OUT ultracall. Ultravisor validates that the address is not a
secure address. However the ultravisor must also ensure that the
address is a valid normal address, within the range accessible by the
hypervisor. A bad address can hang the system.
Reduce the size of TSS code:
TSS library code is about 50% the size of the ultravisor source code.
Most of the functionality provided by TSS code is not used. Prune the
unused TSS library code. This can signficanlty reduce the size of the
ultravisor.
Misc:
The source code is sprinkled with @todo at the appropriate location.
----------------------------------------------------------------------------------