My undergraduate thesis on a capability based security system for a data-centric operating system.
results
+20
-32
+20
-32
5-results.typ
+20
-32
5-results.typ
···
18
18
// take measurements without security checks too so you can see the security overhead
19
19
//
20
20
21
-
== Validation
22
-
23
-
The first test is a basic scenario as a check to make sure the system is behaving as intended, and
24
-
a more expressive test to demonstrate the flexibility of the model. Eventually, I intend to work with
25
-
my advisor and peers to form a proof of correctness for the security model, as well
26
-
as empirical testing to demonstrate its rigidity.
27
-
28
-
=== Basic
29
-
TBA
30
-
== Expressive
31
-
TBA
32
-
33
-
34
-
== Micro Benchmarks
35
-
Additionally, we have microbenchmarks of core security operations in Twizzler. All
36
-
benchmarks were run with a Ryzen 5 2600, with Twizzler virtualized in QEMU. Unfortunately
37
-
I ran out of time to perform benchmarks on bare metal, but hope to find
21
+
We have microbenchmarks of core security operations in Twizzler. All
22
+
benchmarks were run with a Ryzen 5 2600 with 16 gigs of ram, running Ubuntu
23
+
22.04, with Twizzler virtualized in QEMU. The storage backend for all created
24
+
objects was volatile. Unfortunately I ran out of time to perform benchmarks on
25
+
bare metal, but hope to find
38
26
any discrepencies between virtualized and actual performance in future work.
39
27
40
-
=== Kernel
28
+
== Kernel
41
29
42
-
The kernel benchmarking framework takes a closure ( a block of code we want to benchmark ),
43
-
runs it atleast 100 times, and scales the number of iterations to reach 2 seconds of total runtime, and stores
44
-
the time it takes for each run. Then it computes the average, and the standard deviation from the timings.
30
+
The kernel benchmarking framework takes a closure ( a block of code we want to
31
+
benchmark ), runs it atleast 100 times, and scales the number of iterations to
32
+
reach 2 seconds of total runtime, storing the time it takes for each run. Then
33
+
it computes the average, and the standard deviation from the timings.
45
34
46
-
There a couple of things we benchmark inside the kernel, including core cryptographic
47
-
operations like signature generation and verification, as well as the total time it takes
48
-
to verify a capability.
35
+
There are a couple of things we benchmark inside the kernel, including core
36
+
cryptographic operations like signature generation and verification, as well as
37
+
the time it takes to verify a capability.
49
38
50
39
#figure(
51
40
table(
···
95
84
total time taken for the verification of a capability. It's also important to
96
85
note that this cost of verifying a capability for access is done on the first-page fault, then the kernel uses caching to store the granted permissions and
97
86
provides those on subsequent page faults into that object. In the future, I hope
98
-
to measure the difference between a cached and uncached verification. Secondly,
99
-
we only measure verification inside kernel space; as discussed in section 3,
100
-
capability creation only takes place in user space.
101
-
87
+
to measure the difference between a cached and uncached permissions calculation, as well
88
+
as how many practical accesses are granted using the cache compared to capability verifications.
102
89
=== UserSpace
103
-
Userspace benchmarks were calculated using rust's built in
90
+
Userspace benchmarks were run using rust's built in
104
91
#link("https://doc.rust-lang.org/cargo/commands/cargo-bench.html")[benchmarking tool].
105
92
106
93
In userspace, we benchmark keypair and capability creation, as these operations are core to
···
141
128
to form its signature, which is why it's in the same ballpark as the signature creation we saw earlier.
142
129
143
130
The high standard deviation in Keypair objects and Security context creation happens from the
144
-
unpredictable time it takes for the kernel to create an object on disk. The reason keypairs
145
-
are almost 2x more expensive since they create two separate objects, one for the signing key,
146
-
and one for the verifying key.
131
+
unpredictable time it takes for the kernel to create an object. The reason keypairs
132
+
are almost 2x more expensive because two separate objects are created, one for the signing key,
133
+
and one for the verifying key. Performance gains would only be possible from optimizing
134
+
how the kernel creates obejcts.
thesis.pdf
thesis.pdf
This is a binary file and will not be displayed.