MachineOS: a Trusted, SecureBoot Image-based Container OS
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 |
| |
| 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/61543 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023213 / 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
IcosahedronVirtual machineComputer-generated imageryComputer animation
00:14
Identity managementChainPublic key certificateRevision controlStructural loadEncryptionComputing platformFormal verificationReading (process)Extension (kinesiology)RootChainInformation securityPublic key certificatePoint (geometry)Operating systemData centerPublic-key cryptographyInformation privacyPhysical systemComputing platformNumberInformationMinimal surfaceFocus (optics)Integrated development environmentKey (cryptography)Disk read-and-write headAuthenticationData storage deviceUniqueness quantificationProduct (business)Identity managementComputer hardwareSoftwareRun time (program lifecycle phase)
04:47
Sign (mathematics)Lattice (order)Raw image formatComputer animation
07:24
Component-based software engineeringRun time (program lifecycle phase)Installation artMaxima and minima
09:17
BootingFormal verificationStructural loadRead-only memoryComputer-generated imageryComputer hardwareProcess (computing)DatabaseElectronic signatureSkewness
10:45
Process (computing)BootingFirmwareKernel (computing)RootComputer-generated imageryWorkloadProduct (business)Pivot elementPublic key certificateFormal verificationData integrityGEDCOMConfiguration spaceEinheitswurzelContinuous functionAdditionMoore's lawRevision controlRun time (program lifecycle phase)Data storage deviceView (database)WhiteboardPhysical systemMeasurementKey (cryptography)Service (economics)Medical imagingBootingQuicksortFile systemKernel (computing)MathematicsRevision controlProduct (business)Integrated development environmentSynchronizationRun time (program lifecycle phase)Formal verificationAdditionRepository (publishing)Configuration spaceSoftwareElectronic signatureDatabaseCASE <Informatik>Block (periodic table)Reading (process)Matching (graph theory)Read-only memoryMultiplication signLine (geometry)Computer animation
15:37
Program flowchart
Transcript: English(auto-generated)
00:08
And I'm going to talk to you today about MachineOS.
00:21
MachineOS, we've been working on for a couple of years, and its design points are focused on appliances for data centers, so it lights out hands-off environments. And over years ago, we presented at the Linux Security Summit
00:40
some details about securing secrets and TPMs for data center advisors with some of the information about how we are going to keep those secrets in these environments. And so the key pieces that we've incorporated from that design discussion from MachineOS
01:01
focus on use of security platform and the TPM2 device that we need to guard a unique identity and keys that would be placed into a deep key that would be used for identity and device authenticity.
01:20
And further, the operating system will be able to extract the deep key secrets if we have securely moved it all the way up to criminal user's heads and that the chain of trust is still verified. It ensures that we are the device, on the device we expect, and we run it in software we expect as well
01:41
before we can access these secrets. We also include support for unintended decrypted storage for access to data protection and incorporating continuous updates. The root of trust for MachineOS is a certificate of an associated key pair
02:03
which will be protected in TPM hardware. The certificate holds a product ID and a serial number that binds it to the physical system that we are using. And then, picking the certificate key pair in TPM,
02:21
those are inserted at manufacturing time, and then the certificate will give us a mutable identity to verify that the device is authentic and that we'll be running the software that the product expects and that it hasn't been tampered with.
02:43
At the runtime of DevOps MachineOS, we start with our advice for keeping Texas from going into
11:17
unexpected exchanges.
11:24
We loaded and we're executing sort of a normal view of how the kernel comes up. We're transitioning to the loaded-in MFSes startup. And then we get into where the MachineOS trades are running. We're going to unlock decrypted storage
11:41
to pull out our EA policies that are loaded into the TPM and we just have to access the registers to make sure that the values in these registers are what we expect. If they're not, then we help the system run off on to the board for something that's been modified for tampered with. And we don't have access to
12:01
any of the secrets in the TPM that we've locked away. On success, though, we can go over the trust keys and certs, which pass phrases that are protected in the TPM, loaded into the TPM, and used for only by the user. And then once we have extracted that information,
12:21
we extend the XR7 with our own measurement which will protect further access to the TPM from any of the runtime services. Before we start the containers of the runtime service, we brought along that we have to go through steps to ensure that
12:42
the images that were included on the system match the product and the product's expectations. And these will have been signed by the product certificates to verify certificates, signatures, and that all lines up well.
13:01
So for each of the OCI images in the manifest, those will be mounted and then the services can be started. We also auctioned into a particular OCI which gives us a custom environment. We're perfectly fine
13:20
running just out of the area. To the OCIs, we want to ensure that the image and the storage haven't been modeled. And the way we do that is the stacker builds us a squash request for all the layers in the
13:40
OCI, which is a read-only file system that is mounted. In addition to the squash request layer, the OCI images have varied matches that were calculated at build time. And with that, we can build a dean-ferrin block device in Linux which, on access as we read the first time we accessed that block device, the kernel will
14:02
do the work of hashing and evaluating whether that block is valid or it's been tampered with. In the case that it's been tampered with, then the IO for reading will fail. The tampered will stop. The system can be rebooted. We won't move any further on the system. For more details,
14:22
later today, my colleague Scott Moser will be in the Containment Dev Room at 1405 talking more about this in depth. Please go see him later. For our updates, we have continuous updates
14:41
as we can sync from our image repository. An update is much like what we do when we boot up. We have to go through the same sort of verification of signatures such that we know that this is the software that's expected for the device that we're running on and that all of the layers that we pulled out have been signed correctly.
15:00
Once we've applied that, we can update our configuration database to point to those versions. For currently executing containers, we can restart them, but if we have changes to reboot RFS or UKI, we'll need to reboot the system so that we can execute the new versions.
15:21
Lastly, for offline protection or other prevention of maybe there's sort of an excellent challenge or a zero-day run over kernel, we need to talk about verification. And we should not ask those verification