A Rusty CHERI - The path to hardware capabilities in Rust
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Title of Series | ||
Number of Parts | 542 | |
Author | ||
License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/61629 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FOSDEM 2023284 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
MUDCompilerArchitectureSoftwareService (economics)Computer hardwareBoundary value problemCompilerOperations researchReduced instruction set computingRun time (program lifecycle phase)Temporal logicExtension (kinesiology)Address spaceConstraint (mathematics)Pointer (computer programming)Information securityDigital signalCodeTerm (mathematics)Computing platformDisintegrationBound stateoutputParsingType theoryRange (statistics)SpacetimeDifferent (Kate Ryan album)Array data structureElectric currentCore dumpParameter (computer programming)Hybrid computerPrimitive (album)Asynchronous Transfer ModeSoftware testingLibrary (computing)HypothesisClique-widthSeries (mathematics)ImplementationCompilerComputer hardwareConstraint (mathematics)Total S.A.Pointer (computer programming)Type theoryOperator (mathematics)MathematicsSpherical capParameter (computer programming)Address spaceCommunications protocolRun time (program lifecycle phase)Data compressionLibrary (computing)ResultantDefault (computer science)CASE <Informatik>Structural loadBlock (periodic table)Arithmetic progressionComputer configurationObject (grammar)Information securityResource allocationValidity (statistics)Normal (geometry)LengthModal logicProjective planeArmMultiplication signSoftware testingHypothesisAsynchronous Transfer ModeFront and back endsDifferent (Kate Ryan album)Hybrid computerCore dumpRange (statistics)CodeSpeicheradresseMetadataBound stateComputing platformComputer architectureTemporal logicMereologySoftwareCausalityError messageCodeSpacetimeExtension (kinesiology)Service (economics)Boundary value problem
08:33
Program flowchart
Transcript: English(auto-generated)
00:05
So, my talk is about modifying the Rust compiler to support Cherry's hardware capabilities. I'm going to start off with a brief introduction. My name is Lewis Revel and I work for a company
00:21
called Embercosm. I work on many things but I'd say I specialise in developing LLVM backends for constrained or unusual architectures. Embercosm itself is a software services company. We operate in the boundary between hardware and software, particularly in the embedded space
00:41
where you can find many unusual, difficult and interesting problems like writing compilers. So, what is Cherry? It's an acronym Capability Hardware Enhanced Risk Instructions. It's best described as an instruction set extension which can be adapted and applied to different architectures. The main feature of Cherry is that you can encode
01:03
access constraints on memory addresses using things called capabilities. Capabilities essentially have metadata alongside memory addresses that allow you to specify these access constraints. Capabilities can only be operated on using capability operations which replace the
01:24
normal pointer operations and these operations utilise the metadata to enforce those access constraints. It's worth pointing out there are two modes of operation for Cherry. There's pure cap mode where all pointers are capabilities and in hybrid mode you have
01:44
pointers by default on normal pointers but capabilities are annotated as such in the source code. So, capabilities together with capability operations allow you to enforce spatial referential and temporal safety in the hardware at runtime. Spatial safety is to do with
02:05
disallowing accesses out of bounds of an original allocation. Referential safety is disallowing accesses without valid provenance and temporal safety means that if the lifetime of an object is over you can no longer access it through a capability. So, what about
02:26
integrating Cherry and Rust? Well, we're working on this as part of a project which is led by our customer CyberHive and they're funded in turn by Digital Security by Design which is a UK government initiative. CyberHive want to use Cherry hardware to enhance secure network
02:43
protocols that are written in Rust. So, the goal for us then is to produce a Rust compiler that's capable of targeting Cherry-based architectures with the long-term goal of a stable compiler that can produce production-ready code for security purposes and we know that we're
03:00
initially going to be targeting Arm's Morello platform. So, other than being able to compile existing Rust code for Cherry, what's the motivation behind integrating Cherry and Rust? Essentially, it boils down to another layer of protection. We know that Rust is good at
03:21
identifying and enforcing access constraints at compile time but with Cherry you can identify constraints at compile time and enforce them in hardware at runtime. So, a good example is that Rust code annotated with Unsafe is often a necessity in many real-world projects which
03:42
means that it could behave badly but we don't know until runtime. With Cherry you can prevent this bad behavior in hardware when it occurs at runtime. There's some other small side benefits such as replacing slow software bounds checks with hardware bounds checking and replacing pointer plus length types with Cherry capabilities. So, to make things more clear I have a motivating
04:08
example. So, say we want to add a dynamic offset to a pointer and then load from that pointer. Well, this needs to be done in an unsafe block because we don't know until runtime if it's
04:21
going to do something bad. Without Cherry you could end up accessing out of range of your original allocated array but with Cherry that access will not occur at runtime and the hardware will either panic or give you something, a default value. So,
04:43
now that we know that we want these benefits how do we go about modifying Rust to get them? The main problem is that we need to account for capability sizes correctly. That is, we need to stop assuming that pointer type size is equal to the addressable range of the pointer. Because capabilities have metadata this isn't the case. Also in LLVM,
05:06
in the Cherry LLVM fork, capabilities are pointers in address space 200 whereas in Rust it seems like we assume that all pointers to data are in address space zero. Also if we want to support
05:20
hybrid mode we need to be able to specify different pointer type sizes for different address spaces so address space zero will have different sizes from address space 200. One thing I hope doesn't require many changes is that we need provenance and bounds to be propagated through the compiler because they need to be attached to capabilities.
05:43
And of course if we want the optional bonus stuff we need to implement that as well. Progress so far, so the data layout changes are completed which means that we can correctly specify capability sizes both the type size and the addressable range for both pure cap and
06:02
hybrid mode. I've modified APIs which produce pointer types to get rid of the assumption that APIs require an explicit address space parameter. And the biggest change is that
06:20
for APIs where we have a where we report a size for a type this is replaced with a total type size and a size of the value that you can represent. And yeah this means that like I said before we can support Cherry capabilities. There's also in the strict provenance
06:43
API there is an explicit unsafe method of producing pointers with no provenance from a use size. And for Cherry we need to use Cherry operations to set the address of a null capability to achieve the same result. What I'm currently working through is trawling through assertion
07:04
failures that come up when building the core libraries with this modified compiler. What still needs to be done? Well there's almost definitely going to be modifications to the libraries to remove any assumptions that break for Cherry. There's also the question of how do
07:23
we specify capability types in hybrid mode and because I don't think that Rust annotations are the right tool to specify a specific pointer as being a capability I think this requires a replace a size with a type size and added a size of the value that you can represent.
07:48
We need to go through all of those uses of the type size and see if they should really be using the size of the value that you can represent because this is the main cause of the errors that I'm seeing in building the libraries. And of course a lot of testing and
08:03
polishing is going to be required. Before I finish the talk I do need to mention that there's ongoing and past work that is in this same area. There was a master's thesis from the University of Cambridge and there's another government funded project from the University of
08:20
Kent. And well thank you for listening. Please feel free to check out the code on GitHub or ask me any questions outside.