Process-based abstractions for VM-based environments
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 | 287 | |
| 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/57115 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022222 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
Pointer (computer programming)MereologyMoment (mathematics)Message passingEngineering drawingComputer animationMeeting/Interview
01:04
Student's t-testTouchscreenAreaNumberComputer architecturePhysical systemAddress spaceInformation securityMathematical singularityMeeting/Interview
02:00
Information securityPoint cloudNeuroinformatikSound effectSurfaceMikroarchitekturSide channel attackLatent heatMeeting/Interview
02:45
NeuroinformatikProjective planeAddress spaceAuthorizationMultiplication signPoint (geometry)Physical systemDistribution (mathematics)View (database)SoftwareInformation securityMeeting/Interview
04:01
Lattice (order)Right angleMeeting/Interview
04:47
Dimensional analysisSoftwareCondition numberIntegrated development environmentAreaOnline chatMeeting/Interview
06:00
Social classIntegrated development environmentCondition numberDefault (computer science)SoftwareNeuroinformatikSemiconductor memoryCombinational logicMeeting/Interview
07:15
System callFlow separationPhysical systemMereologyOperating systemCartesian coordinate systemElement (mathematics)Computer hardwareMeeting/Interview
09:09
MereologyCondition numberSemiconductor memoryMechanism designMeeting/Interview
09:59
Different (Kate Ryan album)NumberCASE <Informatik>Internet service providerData integrityComputer hardwareNeuroinformatikMeeting/Interview
11:03
SoftwareComputing platformCASE <Informatik>Computer hardwareLevel (video gaming)Military baseDifferent (Kate Ryan album)Meeting/Interview
12:05
Computer hardwareRootType theoryMeasurementCryptographyRight angleSpeicherschutzMechanism designMilitary baseSemiconductor memoryMeeting/Interview
12:58
Moment (mathematics)Data conversionOpen sourceLevel (video gaming)Element (mathematics)Core dumpCategory of beingChainFirmwareComputer hardwarePropositional formulaCartesian coordinate systemEndliche ModelltheoriePoint (geometry)BefehlsprozessorRight angleCASE <Informatik>Dependent and independent variablesData miningMeeting/Interview
14:55
RootSign (mathematics)Computer hardwarePoint (geometry)Parameter (computer programming)FirmwareChainSoftwareWorkstation <Musikinstrument>Meeting/Interview
15:45
Shared memorySoftware developerOpen source2 (number)NeuroinformatikDirection (geometry)FirmwareComputing platformFreewareDifferent (Kate Ryan album)Information securityArmAbsolute valueMeeting/Interview
17:13
Open setFirmwareOpen sourceComputer hardwareView (database)Physical systemMeeting/Interview
18:02
Integrated development environmentSelf-organizationOnline chatINTEGRALMeeting/Interview
18:53
Cycle (graph theory)1 (number)Virtual machineInstance (computer science)Latent heatCryptographyMeeting/Interview
19:53
Different (Kate Ryan album)CodecBitMereologyRight angleVirtual machineWindowAbstractionType theoryFirmwareMeeting/Interview
21:14
ArmQuantum stateEndliche ModelltheorieDifferent (Kate Ryan album)Point (geometry)Term (mathematics)Computer hardwareDecision theoryRight angleMereologyMeeting/Interview
23:09
AngleDifferent (Kate Ryan album)Point (geometry)DeterminismSystem callSoftwareInformation privacyIntegrated development environmentMeeting/Interview
23:58
DatabaseBitDeterminismWorkloadFunctional (mathematics)Single-precision floating-point formatIntegrated development environmentMultiplicationMeeting/Interview
24:52
EncryptionMixed realityVirtual machineProcess (computing)Dimensional analysisSoftwareMeeting/Interview
25:44
Element (mathematics)Computer hardwareAddress spaceExtension (kinesiology)VirtualizationNamespaceCartesian coordinate systemFocus (optics)Meeting/Interview
26:39
Kernel (computing)Data conversionIntegrated development environmentVirtualizationNamespaceMedical imagingRight angleProjective planeLevel (video gaming)BitBoundary value problemQuicksortExpected valueRun time (program lifecycle phase)Moment (mathematics)Entire functionMeeting/Interview
28:58
Right angleVirtual machineDomain nameCartesian coordinate systemHeegaard splittingInformation securityFlow separationMoment (mathematics)Context awarenessQuicksortComputer architectureDependent and independent variablesNeuroinformatikCASE <Informatik>Overhead (computing)Meeting/Interview
30:22
Virtual machineDifferent (Kate Ryan album)CASE <Informatik>Cartesian coordinate systemMereologyAddress spaceSemiconductor memoryTerm (mathematics)Physical systemAbstractionType theoryInteractive televisionFlagEncryptionMedical imagingRootArithmetic meanMeeting/Interview
32:09
CASE <Informatik>Entire functionTorusSemiconductor memoryMedical imagingMeeting/Interview
33:15
Shared memoryMedical imagingCartesian coordinate systemRight angleSet (mathematics)Semiconductor memoryDifferent (Kate Ryan album)Functional (mathematics)Shift operatorAddress spaceCASE <Informatik>Meeting/Interview
34:12
Point cloudPhysical systemSpeicherschutzCartesian coordinate systemType theoryAuthorizationMeeting/Interview
35:09
Lie groupData analysisLatent heatProduct (business)Process (computing)Cartesian coordinate systemMeeting/Interview
35:54
Process (computing)Library (computing)Direction (geometry)EmulatorPhysical systemMeeting/Interview
36:45
Single-precision floating-point formatCASE <Informatik>Process (computing)Ring (mathematics)MereologyLibrary (computing)Virtual machineAddress spaceKernel (computing)Meeting/Interview
38:25
Cartesian coordinate systemLimit (category theory)Semiconductor memoryProgramming paradigmComputer programmingDifferent (Kate Ryan album)Suite (music)CASE <Informatik>QuicksortView (database)Binary codeStandard deviationMeeting/Interview
40:32
Curve fittingAnalytic continuationDifferent (Kate Ryan album)Direction (geometry)Standard deviationMoment (mathematics)File formatFitness functionGroup actionAbstractionData managementQuicksortProcess (computing)Similarity (geometry)Meeting/Interview
42:03
Cartesian coordinate systemWordPhysical systemBitPoint (geometry)Address spaceLevel (video gaming)Group actionSoftwareComputer hardwareNeuroinformatikLibrary (computing)Side channel attackSingle-precision floating-point formatTerm (mathematics)CASE <Informatik>Meeting/Interview
43:53
BitConnectivity (graph theory)Right anglePhysical systemInformation securityMeeting/Interview
45:02
Source codeMultiplication signCASE <Informatik>Functional (mathematics)AuthorizationRight angleMeeting/Interview
45:51
TorusMeeting/Interview
46:35
BitAddress spaceSemiconductor memoryCapability Maturity ModelComputer architectureState observerGame controllerCartesian coordinate systemMereologyInjektivitätPrimitive (album)Run time (program lifecycle phase)Software developerSymbol tableSimilarity (geometry)TorusInformation securityKernel (computing)Level (video gaming)Maxima and minimaCASE <Informatik>Extension (kinesiology)Goodness of fitMeeting/Interview
48:46
Terminal equipmentType theoryMultiplication signNumberFormal languageMultiplicationSimilarity (geometry)Meeting/Interview
50:12
Programming languageTerminal equipmentMereologyMeeting/Interview
51:21
Line (geometry)Term (mathematics)Terminal equipmentSide channel attackMeeting/Interview
52:34
Kernel (computing)Lattice (order)Software testingEndliche ModelltheoriePatch (Unix)Vulnerability (computing)Meeting/Interview
53:31
No free lunch in search and optimizationInterface (computing)Type theoryCartesian coordinate systemHeegaard splittingSide channel attackMeeting/Interview
54:54
MikrokernelSingle-precision floating-point formatComputing platformIntegrated development environmentMehrprozessorsystemAbstractionMeeting/Interview
56:01
Different (Kate Ryan album)SeitentabelleSingle-precision floating-point formatFlow separationMeeting/Interview
57:07
View (database)Point (geometry)Self-organizationoutputMeeting/Interview
57:58
Meeting/InterviewComputer animation
Transcript: English(auto-generated)
00:22
And it's not a private party, so everyone who wants to take a part in this discussion, please drop a message to each of you. You can ask questions in the chat or you can join our discussion, so feel free.
00:42
I think we can wait, let's say, for a moment when people come or somehow demonstrate they are willing to join the party. What do you think?
01:03
I'm lazy, whatever. Okay. Can we tell who's on? Oh, yes, probably we should introduce ourselves. But I think many of us already gave it up today. So I'm a research fellow at Imperial College London.
01:24
I'm working in the area of prostate computing system architecture operating systems. Number one, who is next? It will be Hugo, he is the second in my screen. So hey everyone, I'm a PhD student at the University of Manchester.
01:43
I'm working in the area of operating systems and security. I do unikernels, I do compartmentalization and singular space operating systems to be high-level. Jethro. Yes, hi everyone.
02:01
I'm Jethro Beekman. I got my PhD from UC Berkeley five years ago where I studied cloud security. Now I'm a technical director at Fortanix. We're probably the first startup doing anything in confidential computing five and a half years ago. Yo.
02:26
Hi guys. Yes, I was planning to figure out how to shadow. I am Yo. I work as a postdoctoral researcher in Caleb. I've worked mainly on a specific side channel effects micro-architectural attack surface in TES.
02:44
Mike. Hi. Yeah, I'm Mike Massel. I'm co-founder of the Enarx project and co-founder and CEO of Profium, which is a startup in the in the confidential computing space. Obviously, I started a long time after Jethro's lot at Fortanix, but we're still here.
03:01
I'm also author of this, which is Fras and Wear. It's the first book which kind of deals with confidential computing in a tool, really. So and a whole bunch of other stuff. Came out last month, about a month and a half ago. Who is the last? Hello, I'm Marta.
03:21
I do have PhD in network security. I was working on anonymity systems at the time. And then I spent ten years in silicon. So I can give you that silicon point of view of all those technologies. And now I'm doing distributions.
03:44
I'm working on Eclipse on Neuro. So interested now in how to use all those technologies in one single place. And make it useful for the for the end user in an embedded market.
04:01
OK, thank you very much. Did we start another conversation? Yeah, I think we're still the same. Oh, join. I see another Jitsi. Yeah, I'm saying that's if I join it.
04:21
Should we join the other Jitsi? No, I think this one is getting streamed to the dev room, right? So, yeah, I wouldn't join the other one. Not sure. I will not join that one. OK, let's take it. I've got removed for everyone. Shall I do that?
04:43
I can't just leave it. Right. So, Vasily, do you want me to just introduce this topic I suggested? Yes. So, OK. So I think nobody is coming. And if somebody has questions, he or she will post them into a chat.
05:00
I think everybody agrees that we can start. So what I would like to discuss is in general how we see trusted execution environments. And I grouped such questions into three separate areas.
05:21
So the first question is, or the first topic, let's say, what is trusted execution environment as a technology? What are the official conditions for technology to be considered as T? And is there a social dimension of T? Maybe the reason the way how you use this is defined technology as T.
05:45
Or maybe there is a software or maybe software somehow impacts this terminology. What's your opinion? So I have the question out and back.
06:01
Sorry, I've lost this. You lost. OK, so the question I have several questions to you for this class. And my first question is, what is the trusted execution environment as a technology and what kind of official conditions for technology should be to be the technology considered as a trusted execution environment?
06:23
So what, for example, why do we think that SGX is a trusted execution environment while, for example, non encrypted VMs are not? So just to kick off shortly, I would say that T gives you isolation and attestation of some form.
06:43
Isolation can go from encrypted memory to software only adversaries. And attestation gives you a reason to trust the entity that is being isolated. And I think if you think, for instance, about micro kernels, they don't give you attestation by default.
07:03
So I wouldn't say that's a T. And, yeah, the computing base can be hardware, software or a combination of both. That's how I see it. OK, Jethro, you're the next. Yeah, no, I basically I was going to say isolation and attestation, so you took the word out of my mouth.
07:25
OK, so who else thinks that there is something else except isolation and we now have only four, where are the rest?
07:43
OK, Minos, Mike, Tehanie, Felicia, OK, OK, no worries. OK, Marta. In fact, to prepare answers to my to my friends who are asking me exactly that question, what is a T? I was been reading a lot of definitions and you can find more or less everything in them.
08:10
How I define a T myself, it's it has to be some hardware elements that gives the application part
08:21
strong separation from the operating system itself. That's the reason why I wouldn't call systems MMU a T, because in some definitions you could you could think of as such.
08:43
Quite often people mention attestation. But in practice, I've seen also a lot of examples where attestation is actually not provided. Deficiency separation attestation is nice to have.
09:05
And we'll see how it goes in the future. Sorry, I've just got back. What was the question? Sorry, I caught an interesting end to an answer, but I didn't get the question. The question is, what is the definition of trusted execution environment?
09:21
What conditions are sufficient for technology to be considered as T? It's the first part of the question. Yeah, so it's an interesting one. Should I have a go at it or do you, Jethro, have you had a go? I already provided at least two things, isolation and attestation.
09:44
OK, so I again, depends what we mean by isolation. And also, do we do want to specify a mechanism like, you know, memory encryption? It will be delayed later. It's a later question.
10:02
Yeah, so another there are a number of different definitions in the industry. I mean, the Confidential Computing Consortium, which is kind of the industry body around confidential computing, which is arguably allowing you to do things with TEEs, specifies that confidential computing is about using hardware based TEEs to provide confidentiality and integrity protection.
10:29
Doesn't really answer the question about what a TEE is. But I mean, there's a question on one of the things that you might say is, for instance, that TrustZone isn't on its own, a TEE, but one when you use something like, what's it called, Opti, then it becomes a TEE.
10:45
So I also like the question as to whether attestation is required or not. I can't see use cases that leap out at me for using TEEs without attestation.
11:02
OK, I have an example. Let's say I have a verified, very tiny micro-hypervisor, and this very fancy tiny micro-hypervisor provides you software based attestation for your VMs. So this would be a TEE platform.
11:23
Well, again, I'm going to come back to a hardware based TEE and by hardware, I mean that we have the capabilities of isolation being provided by the hardware. And also, I'm going to insist in that case that any attestation is based in the hardware as well.
11:40
Define hardware. I mean, SGX instructions are mostly a microcode. So this microcode is stored inside an enclaves and it use different low level instructions. So, I don't know, Intel architecture, but in essence, in some way SGX can be considered as a software defined isolation.
12:04
Yeah, but I said hardware based. So when it comes down to it, it's using chip based instructions. Right. And what's more, the cryptographic root of trust goes through the microcode and into the hardware.
12:22
So any attestation measurement you're getting includes both. So Mike, we've seen a couple of other types of enclave technologies like, you know, Amazon, Nitro Enclaves, Keystone.
12:45
These don't really use any special features. They just use existing memory protection mechanisms. Right. Like the MMU memory protection, hardware based. So I think that according to the Confidential Computer Consortium that it isn't.
13:05
But that is a conversation that is being had at the moment. I think this is not an easy one to come down to. I'm asking about your opinion. From what I know of Nitro.
13:21
I'm going to say no, but that's partly because for me, one of the important capabilities or properties that T provides is the ability not to have to trust any element of the hardware apart from the CPU and its firmware.
13:40
And that is not provided by AWS. You have to be trusting AWS as well. Right. My understanding is from what I understood of Raoul's talk as well. I was really hoping that the founder was going to be here because this is much more his his level than mine and his very much his expertise. But that would be, I think, my main my main response to that.
14:01
The model we take in Enarx is that there's three things you should trust. One is the application in which, let's face it, you wrote it or you got it from somewhere. So you kind of got to trust it. Two is the Enarx code, which is all open source. And three is the CPU and its and its firmware, which are cryptographically verified on each on each use.
14:26
Now, I say CPU in the future. I'm sure that's going to be GPU and DPU and all other things as well. But for the for the purpose of this discussion, that's where that would be my starting point and not having to trust. In fact, being able specifically to distrust everything else in the in the in the chain is core to the
14:45
value proposition that I think that TEEs bring to many use cases of which I include the edge and cloud. I think that last point about not trusting something is indeed also key to a definition of a TEE.
15:01
I think what TEEs allow you to do toward the station is to be explicit about what you trust and what you don't trust. I personally think it's less important whether that trust is in hardware or not. Well, you usually have a root of trust at some point in hardware. But I agree with the comment from Vasilje that SGX is essentially also a layer of firmware.
15:21
It is too quote in between. And when you look at things like RISC-V Keystone, they explicitly make an argument to move as much as possible to a software layer that performs similar capabilities than what others do in hardware. But as long as you measure that, I think that that is an important requirement.
15:44
Yeah. Measure and sign. Obviously, you need to have the root of trust all the way down the chain of trust all the way down into the hardware. I think it's very important. I think also perhaps something others can comment on or share thoughts on. We are here at the Free and Open Source Software Developer Summit, right?
16:01
I am personally thinking that the direction that Keystone is going, where more of the computing base is accessible and modifiable and inspectable. Essentially, the owners and the users of the platform has benefits over what SGX does, where it's all baked in a non-transparent firmware. Not sure what people want to comment on that.
16:22
Yeah. I mean, actually, I've spoken a lot. I'll shut up for a second. I will share maybe on this subject. I'm looking forward to all this firmware to be more easy to inspect. Because from my different experiences in security and other places, I really fear of attacks on the firmware and the hardware itself.
16:56
So the more of that is open source, the more of that to try to find holes, the more reasons to actually trust that solution we're going to have.
17:12
Oh, yeah, absolutely. And I think one of the things that Arm has been saying is that they are hoping to make more of their firmware open source, as well as my understanding.
17:22
Other people have that? That's what I've been hearing, I think. I'd certainly welcome that for everybody. My view is that everything should be open source all the way down to the hardware. But I don't think we can expect that in most cases. I do think that transparency can help a lot in mitigating some of the trust issues that you would otherwise have.
17:47
So, for example, Mike, if more of the underlying system for Nitro Enclaves would be open source and auditable by you, do you think that would change how you view the system?
18:01
I think possibly not, given what I understand, if that would help. But from what I understand of the trust model, which is that you still need to trust the person actually hosting the organisation providing the services,
18:21
then I think that is likely to continue to be an issue. You know, if you're looking to operate in a mutually distrusting environment where, you know, the tenant doesn't trust the host and the host doesn't trust the tenant, then you need to be able to take the host, the CSP, out of that trust relationship, at least with regards to the C and the I.
18:45
I know the A, confidentiality and integrity. I know that the availability is much more difficult to do in that context, of course. We have very nice comments from our chat. I don't know what is the delay between us.
19:00
I can't see them. They're being asked in the main Dev Room chat, so you have to open another tab to look at them. I'll try and do that. So, an example that Windows machine has TPM chip. Can we consider TPM as a T? It's actually a very nice example, because TrustZone, which we partly consider as TE, was a regional virtual TPM.
19:24
And the USG, in some sense, also looks like TPM. So, again, it's one of those difficult ones for me, because otherwise you're cycling everything at TE. I think that for me, the big thing about TE is they allow generalised compute, rather than just specific crypto calls, for instance.
19:47
And even TPM2 doesn't generally allow that. OK, interesting. I would agree with that. The main difference between the TPM and the TE for me is that on TPM, you can't run code away. On TE, you can.
20:07
So you can do completely different things with both. TPM usually has a GBM inside, so you in essence can, in theory, run whatever you want.
20:24
OK, I understood the question a bit broader, right? Or specifically mentions a Windows machine with the TPM. I assume it means something more around the, right, like TXT or some other trusted firmware type thing.
20:45
I don't remember what the AMD name is for the same. I think, yeah, maybe. Right. But when you look at that, your TCB is very large. Right. So it may not, the attestation you get out of that is not very useful.
21:01
Right. So while you may could, you know, with some mind bending, could consider it a TE, it may not be a very useful abstraction because the TCB is so large. And that's not to say that you can't use a TPM as part of your attestation change, for instance, because I believe that PF from IBM does that.
21:24
But it's not doing the, you know, I think I'm with Jethro on that as well, the way you put it. I guess part of the, you know, part of the question is, what are we making the distinctions for?
21:47
Why is it important to be able to make distinctions? Right. And there's two ways of looking at it at least. Well, maybe more three. One is so that producers of hardware can, suppliers of hardware can say whether something is a TE or not.
22:03
And that's a useful thing to be able to sell. Right. Two is so that there can be an academic discussion and decisions about how we look at different models of trust and isolation and attestation. Those are all useful. And the third is in terms of the end user. Now, what are
22:20
we what are we selling to them and what are they going to be wanting to use? And again, the CCC, I think, has tried to to to look from that point of view, although, of course, it has interesting rays of eyebrows. But it has Intel and ARM and AMD and NVIDIA and IBM, you know, all members of it.
22:43
And I think this thing about generalized compute is important. I think the attestation is important. And for me, there's a kind of and being able to be very explicit about the trust model for me is important as well.
23:04
Jethro, do you want to respond to the with the eyebrow raise? I'm interested to hear what that is. Actually, my eyebrows are completely unrelated to what you're saying. OK, cool. I have another well, not another point of view, but maybe we can have a look from different angle on this question.
23:24
So does software define or impact the definition of T? So what you run inside is this maybe this can define the T or not. Is there any difference? So if I run Doom or Quake inside SGX or I run, I don't know, privacy preserving software.
23:49
Well, I think, well, while the technology is the same, you unlikely call SGX with Doom inside the T, right? I don't see why not. The T is the thing providing the isolation and the environment to run.
24:03
What you run in it is the workload inside the T. As far as I'm concerned, Doom absolutely have to put Doom inside the T. You can put anything from a single shot function as a service, which just echoes back a single bit to, you know, a full SAP database or, you know, multi,
24:28
multi terabyte AIML workload. As far as I'm concerned, it's not that's not what defines the T. It's it's the it's the isolation and execution environment and execution and trusted execution environment.
24:43
You know, the clues in the name which defines what it is, not what's running inside it. OK, can we move to the second question or we have somebody will have something to add.
25:01
It seems the software dimension of T isn't considered as a definition. OK, let's come back. Let's more close to technologies. Actually, we have two fundamental questions. So VMs or enclaves, what of them what what of those what are those technologies more practical, reasonable?
25:29
Well, probably right or wrong. What's your opinion? They represent completely different abstractions. One is the inter process isolation with encryption. The other one encrypted virtual machines. What do you think? Someone else got to go first.
25:47
I would run first and we run into the whole story of third element. I would like to see containers. What I have currently what we have currently,
26:00
we have the VM based extensions and we have SGX kind of thing that I think we could make work with with containers. But currently we have those we have also containers that are taking a lot of space. And from the hardware we've been to this less, less focus on that.
26:25
But on the application side, it's there's a lot of interest in in containers. And I'm wondering if you know of any research of using those technologies exactly in containers. But what do you mean by container? Because usually container is a namespace virtualization.
26:44
It's a namespace virtualization. So you have a shared kernel. Kernel gives you a program, an impression that it exists alone in the environment by giving the same 0P for the first program, giving the same names and so on and so forth. So it's only about namespace, not about isolation.
27:02
There's a huge conversation about this. Exactly this topic going on at the moment in the industry and certainly the CCC seeing it. And you can look at it in two ways, I guess. One is a container is an OCI compliant thing, image that runs on within a runtime.
27:24
And so there's I'm aware of two very different approaches to putting containers in TEEs. One is to put basically entire Kubernetes pod in a TEE and run containers like that, which has all sorts of interesting questions around, well, TCB, where your trust boundaries lie, all that sort of stuff.
27:46
And the other is attempt to create a basically have a cryo or equivalent, a container runtime layer, which sits at pretty much the lowest level of a TEE.
28:04
The problem with that is that the container, the OCI expectations about execution don't necessarily tie very well with what the TEEs are and more importantly, what the pod expects to be able to know about the TEE,
28:20
about the container running image. So this is a really complex thing. And I think the question of what is a container is a very fair one for Zilli and very pertinent here. And Marta, what do we mean by to run in a container, to run a container? And it's there's a lot of discussion, two completely different projects going on right now.
28:44
So there's a lot of discussion in the CNCF and elsewhere about exactly these questions. I also think coupling it a bit back to the original question, like, do we
29:03
want or do we need virtual machine-based or sort of inter-process SGX-based enclaves? Perhaps we need both. Perhaps they are complementary, especially if I think about TDX and SGX. I think at the moment it seems they might have complementary use cases.
29:22
Something like TDX is to is apparently you could say it's Intel's response to SAV. It's like very quick, full virtual machine isolation. Whereas something like SGX at least originally seems to have been designed for splitting an application into several security domains of a very fine-gained analyte.
29:44
I think we also learned a lot over the last years. Right. And I think it's the performance overhead of doing that is larger than I think it was anticipated, especially if you think about micro architectural isolation. So I'm not sure how viable it still is to do such context switching within an application frequently.
30:05
And at that point, maybe a virtual machine-based isolation has an advantage with the disadvantage of having a larger computing base, of course. Yes, these are some thoughts on that. I don't know if someone wants to begin on that distinction.
30:20
I think it's interesting because here we might need to define again virtual machine-based isolation because what you were describing as the use case for SGX, we are actually also doing it with virtual machines. In the case of FlexOS, for example, we're using virtual machines to split up an application and we're putting the different parts of the application in different virtual machines.
30:43
So in the end, you could also use virtual machines for that. Certainly you can emulate a single outer space with a VM, right? Which is basically the original topic I tried to get some discussion around, but I'm happy to talk about these points as well.
31:02
I think that the TCB size question is maybe one of the biggest questions that needs to be answered in terms of what is practical and what do people want to do. I think if you just take an existing VM image and then put it in a VM and then turn on the memory encryption flag or something, it's not very useful.
31:24
And the reason is because your attestation doesn't mean anything because your existing VM image just has SSH on it. So your root user can get in and do whatever they want. So it doesn't really mean anything to have that VM attested because it can run anything.
31:40
And this is a general problem with what a lot of people think about when they say VM isolation or things like that. You can use multiprocess abstraction in an enclave type way, but again, you need to kind of redesign your system around it. Something where you take a single OCIA and run that in a VM.
32:02
That may be a much better abstraction because those are already designed not to have user interaction. Yeah, and I'd follow up on what Jethro was saying there as well. And I'm strongly in agreement and say that when you say that the TCB, that makes a very big assumption about what you mean about a VM.
32:22
A VM is just a vCPU and at least one memory page, right? That's all it really is. And that's how we treat it in the NRS case. We treat, you know, we abstract across whether it's a VM or a process. We currently support SGX and support SEV, but we plan to do others as well.
32:40
And we treat them the same. And, you know, we have a tiny microkernel, really very, very small in the in the VM case, you need to have something like that. But you don't need to assume that it's a kind of lift and shift, taking a huge VM and putting it across. And I think that's a if people start using T's like that, well, that's fine.
33:03
I think there's always going to be that use case, but it's not going to be that's not the way the future really lies for these things, because you could do so much more with them. And I think that's where it really starts getting interesting. Maybe I'm missing the point, but if people are putting entire VM images in enclaves to achieve compatibility,
33:23
why not going the way of Grameen that's much more lightweight and still aims to provide really good compatibility? You can still run. The compatibility of taking an actual hypervisor, right, and just running your VM image directly is much better than if you try to shoehorn something into SGX.
33:42
Grameen gives you pretty decent compatibility for some things, but there's other things that don't work at all. Right. Like shared memory and like memory mapped IO. So I don't think we should assume that it's going to be one set of applications. There's going to be different use cases for different applications. There's lots of space in the market for this.
34:02
I'm pleased to say, you know, whether it's going to be your big lift or shift or, you know, single functions or, you know, stuff in between. I would also say that the big question here is, what are people using a TEE for?
34:22
Yeah, you agree? Because if you just put all of your system into a TEE, because you do not trust your cloud provider, that is completely different. I've heard about people having that idea. I don't exactly know where it comes from, but I've heard about that idea.
34:45
And it's completely different than putting one simple authorization application in a TEE when you keep all your secrets in the protected memory. It's completely different. I think that the type of applications you are using a
35:02
TEE for has an important impact on the technologies you can or cannot use. If only we had, you know, the biggest company in the world, you know, with commercial TEE applications. Jethro, what are people using your products for? I mean, products and services, exactly the question, right?
35:21
Yeah, all of the above, right? People use it to protect their deepest secrets. People use it to protect specific data analysis pipelines, right? For example, processing patients or other healthcare data, and people use it to, yeah, basically move their entire application.
35:43
So, like, I don't think we need to, we should be focusing on a specific thing, like people do all of these. Yeah, another way of thinking about it, I guess, is what do TEEs allow you to do? Where can they take you?
36:01
What new things do they allow you to do, new ways of working with the world? That's moving rather a long way from the process versus the end, so I'll stop that. And if you want to talk more about the original topic, we can do that. Sorry. No, but a question that I still have is if the Grameen approach has
36:25
compatibility issues that forbid you from running certain applications, is it something fundamental, you think? Or why not just pushing, putting more efforts towards this direction and getting something that's really lightweight and gives you really good compatibility?
36:44
What I'm thinking about is all the solutions, based on the library system inside this jigsaw, we see just an emulation of encrypted VM. People want to have compatibility, people don't have it in this jigsaw class, and they develop a library of both based solutions to get, in essence, virtual machines that you have.
37:05
There is a huge kernel, there is a muscle libc or other library, and you have almost 100% compatibility, if you speak, for example, SGX-OKL that has Linux kernel library inside. But in my opinion, it's not the proper or originally designed way to use SGX, because you
37:28
don't use the primary feature of SGX that multiple, when the single process can host multiple enclaves. And this multiple enclaves can have shared memory, untrusted, but anyway, or it's a ring three without privileged layer or isolation inside.
37:48
While in the case of encrypted VMs, it's completely different abstraction. As encryption, yes, you can use a single address space. But again, is this an original design of this T?
38:01
I don't know. Well, probably not. So I wouldn't put libos-based solutions that use SGX as original SGX approach. It's not the SGX way. The SGX way is when you have a library or part of your program, and you put it in enclave, and it's protected. That's how I see.
38:27
You can fit whole applications inside an enclave, no problem, right? But you cannot take any application, right? Just because the SGX programming model doesn't support the same things that you would
38:40
get on like a POSIX system, and the limitations are mostly around memory mapping, right? So that's the original question, a different programming model, different extractions. Which of them is better or which of them suits our purposes? Well, I think this comes back to the question of we can talk about containers.
39:01
And, you know, Hugo, you talked about, you know, why not take the gramming approach? And if you want to be writing, you know, monolithic applications, running them, you know, which look like ELF, Linux ELF binaries, then it's great to do that. But we know that that's not the only way of creating applications. And we've, you know, containers, if nothing else, taught us that people are absolutely open to
39:25
writing different, you know, writing things in different ways, creating microservices, all those sorts of things. And I think that TEEs allow the industry and academia to think in different ways about how we do program stuff, how we build distributed systems, particularly.
39:44
And how they trust each other and all those sorts of things. So, again, I think that, you know, there is absolutely going to continue to be a case for, you know, standard ELF binaries being wrapped or run whatever way it may be, that there are new opportunities.
40:01
And whether containers are the way that we do it or other ways come up, you know, we're, Enox takes a different approach. We're saying that WebAssembly is interesting and useful and we're not. You know, there's other people taking the same view and then maybe others will come along. Of course they will. I think that we should, we shouldn't allow ourselves to assume that people are going to continue using things in the way they did before.
40:23
From what I'm hearing from Jethro, that's what you're seeing, right? People are not just doing everything in the old way. Some are, but not everybody, right? But if we go the direction, I'm sorry. I was just agreeing with Mike, so please continue. I just wanted to ask, if we go the direction of containers, what's the difference with confidential containers, Ben?
40:46
Well, first of all, what does confidential container mean? As I, as I already said, there's some really big issues around that. And arguably containers are not a great fit for TEEs as they exist at the moment.
41:00
So we need to think of another thing. Why did containers win? Containers won, or you know, won a thing, arguably for two reasons. One is that the Docker created an abstraction away, an abstraction of lots of complicated C group and other process management stuff.
41:20
That was horrible to use as it was. And secondly, they created a packaging format. So it allowed you to run stuff on a runtime, which is, you know, which is standardized, de facto standard. And that allowed you to package things easily. If we can do similar things with TEEs, and there'll be different approaches, then we can look at things in a different way.
41:41
Maybe containers, maybe an OCI approach is one of one way of doing that, you know, cryo, I don't know. But I think there are issues around whether Kubernetes does that, all those sorts of questions. But let's not allow ourselves to assume that that's going to be the only way.
42:03
Very interesting point. I agree with not pinning ourselves on one way and in a way diversity, both at the software and hardware levels is greater. But I also agree to it for this original point that SGX, I think, was designed for one purpose.
42:21
And then things like Grameen and other library operating systems tried to push applications into enclaves that were not not really meant for that. And I think TDX can be partially a solution for that. If it moves to the to the point where people who want to run legacy applications without doing extra effort to port them to enclaves or to TEEs use technologies like TDX.
42:45
And I think there will continue to be a space for very carefully vetted small applications. Things like porting enclave from Intel is a good example. I think also what single has been doing the single messenger with private contact discovery is a very nice, I think, use case of SGX.
43:00
And it's a bit related to to my research area, but I think such small computing base enclaves with explicit transitions are also more feasible or easier to go in terms of side channel leakage and so on. I think it will be good to consider before you adopt this TEE as a magical solution,
43:24
what do you want and what is the best technology and software tools out there to make it. But yeah, that relates a bit to the earlier discussion also that. I think many vendors are nowadays using this as a bit of a buzz word and we need to think as a community on the longer term.
43:45
How we will standardize the naming or at least the concepts that are being used and then. If you're interested in that, please do get involved with the CCC. You don't need to be anyone can turn up. You don't need to be a member. You can just get involved.
44:00
It's sometimes a bit of a talking shop, but it is at least the industry talking shop. Yeah, I think for non-expert users, it becomes very hard to understand what one technology offers and doesn't offer over the others. OK, I think one thing that is that is often overlooked is that, well, maybe I'm just repeating what I said earlier in a different way.
44:31
Right. But there's no magic bullet. Right. If you if you want better security for things, you may need to re-architect your system and
44:41
you may need to better understand, you know, how components fit together, what components can be isolated, et cetera. Right. And so it really comes down to understanding your your TCB and trying to get it smaller if you if you want to really achieve something.
45:01
OK, thank you very much. Now we will come to the final question from my side. Do we need something else? What else do we need? Beer. What functionality, new functionality from T do we need?
45:23
I mean, is there any risk case that we can't implement because some technologies don't exist and if they were will become something? OK, that's something that I really want. And that is a trusted time source. I was going to mention the same, Mike. It's just such an obvious I know it's not easy, but it's such an important thing.
45:44
Right. For so many use cases, including billing, frankly, it would be really helpful. Yeah. Authorization checks. Yeah. All of these things. Another thing I'd like as well is. If I'd love to have T's and GPUs, but we'll need to look at how we do the trust relationships and attestation is going to be very, very complex.
46:10
Sorry. I just mentioned it's trusty devices is quite obvious. I needed to tell the CEO initially what I would really like to see instead of adding extra features is
46:27
a way to have the existing features to help bring those better. Are you saying no? Am I coming through? No, I basically said something and we didn't hear anything.
46:40
Well, I just said that, well, he wants that existing things start working finally. Well, that's a bit a rough way to say it. But what I think is an interesting observation is that we have a more mature understanding of this. And I think the initial idea was let's try to seclude the part of the application and everything is fine.
47:01
Something like this does not offer you any protection once it goes wrong. And the first talk of today, right, where the Intel engineers talked about all the defense in depth that they have been applying against plain old memory safety attacks in the SDK is a good example of that. We know memory safety attacks for so long as it perhaps was a was a way to deal with that by saying let's minimize the TCB.
47:21
But we have the same problems again. And I think we already know a bit of the solution space there. We know that simple architectural extensions like as map and as map in the kernel to prevent the kernel from reading or executing user space can tremendously help. And I think we should investigate what kind of minimum architectural features we can add to the ease such that you
47:44
can do things like into our enclave protection so that you can enforce principle of least privilege and things like that. During execution, I think also the Guardian talk that we saw today does something similar with symbolic execution, but it's also essentially principle of least privilege, where you try to
48:02
detect during the execution of the enclave, whether it will access things it's not supposed to access. And that relates well I think so these are all architectural features but I think it relates very well also to micro architectural leakages, we want more ISA primitives to enable enclave developers and enclave runtimes
48:20
to more fine grained control micro architectural leakage or injection in the case of Spectre and the like. So I think that there's a lot of potential there as well. And again, I'm especially thinking about those very high security low TCB enclaves things like the quoting enclave and, and so on.
48:45
How about combining combining T's in Cherry? Yes, yes, that's also something I had in mind. In Cherry, well, perhaps Vasily could also say something about that but I think something like Cherry could be very useful to protect enclaves,
49:03
but on the other hand Cherry is more powerful than TE so maybe you could get rid of TE's if Cherry would be widespread. Good question. Can we get rid of TE's? It's a, it's an original question, the first one. What's TE is isolation and attestation, and Cherry is only isolation, and it's a big
49:32
question what would you attest using Cherry, because, because of my mom, because of multiple reasons actually thinking about this quite a long time.
49:43
And, yes, Cherry allows you to finally probably solve problems related to programming using type unsafe languages. But taking into account the number of Rust programs, I don't know, VASM and similar technologies.
50:05
It looks like that maybe it's outdated. Marta anything from you? I would agree with everything you have said, I would maybe, there were great ideas.
50:26
I would enforce the part of being able to use the TE-like technologies, not sure it's going to be really TE or something similar, in programming languages.
50:45
So that the program, if you can, you can spawn a TE from the programming language itself. That would be great to have. And the other thing, I will come back to what Mike said, if the TE's are there today, I will need a Docker for TE's.
51:05
One to rule them all, because if you try to develop for different technologies at the same time, it's difficult. Marta, come and look at that, I'd love to have you. That would definitely help.
51:21
So I've got another thing I'd add to my wishlist actually. Sorry, Jethro, off to you, sorry. Yeah, in terms of my wishlist, it's kind of along the lines of what Jo was talking about in terms of making existing things just a little bit better. I would like physical security, so Intel has basically given up on that.
51:43
But I think it's still possible, so we need better things on that side. You want your TE's to be an HSN? I mean, in a way, I guess. No, I've got it. I'm not complaining, I don't like it.
52:03
HSN is kind of a poorly defined thing, right? I mean, maybe HSN is like a FIPS 140-2 or 3 certified module or so. But those specs don't talk about side channel attacks, right?
52:20
So I don't think HSN is sufficient to cover the definition, right? But no, I liked Intel's original promise, right? But then they said, nope. So I've got another thing on my wishlist, it's a kind of meta, it's not really related, it's not specific to TE's. But I think it's something that's going on the kernel community at the moment, the Linux kernel community.
52:42
Which is, as I understand it, currently there's no threat model for testing and how you think about attacks and attack modeling of vulnerabilities around a compromised or malicious host. And I believe that there is some work going into the kernel community about putting that as one of the threat models
53:04
so that when they are, when folks in the community are looking at patches for SGX or patches for TDX or patches for SEV, that there's actually a way of evaluating whether they're meeting particular criteria. And I think that's got to be a good thing for the community generally.
53:21
It's not the only place you should happen, but if it happens in Linux kernel community, it's a really good start. Sounds interesting. Another thing that I'm exploring at the moment and that I think is very, very important is to not only think about the guarantees that you get from the hardware,
53:44
but also think about the interfaces that your application exposes to the outside world. It's not very useful if you have great, great isolation provided by the hardware, but you're splitting your application and the interface that your application exposes to the rest of the world
54:04
is vulnerable to IAGO type of attacks or confused DPTs and this kind of thing. At the very lowest level, is it ever sensible to have plain text, non-TLS networking out of a TE?
54:23
And then there's a whole logging thing, which I gave a talk, I didn't have any answers to it. But I think absolutely all of these things, side channels is the worst of it. There's so much easier stuff that you can attack without having to go there for most designs. And that's a real concern. And this is, we're the community who need to think about this stuff.
54:41
It's really important that we do. We've got five minutes, four minutes. Actually, so well, my question is an empty.
55:01
Well, I guess we can come back to the topic I proposed. I think Mike maybe touched on it a little bit, right? But we were all familiar with the process-based versus VM-based abstraction, but there are some platforms that only offer one of them, right? And yeah, we've talked about how it is hard to build a multiprocess environment on top of SGX,
55:28
but it seems pretty doable to build a single address-based abstraction on top of a VM-based enclave. So in terms of implementation, what would you like to put inside, right?
55:41
I know, Mike, you have some kind of microkernel. Another thing I've been thinking about, you could take something like CEL4 or something like that, which is also formally verified. But what would you like to put in a VM to make a single address-based abstraction?
56:00
We use WebAssembly. We use WASI. That's our approach. That is what's happening. You still need something that looks like an OS, right? You need something to set up the page tables and the I.O. Yeah, so we have a shim layer, which is architecturally dependent and looks different.
56:26
And obviously, yeah, there needs to be a separation. I think that's one of the interesting approaches that everyone needs to decide what approach you're going to take. And I'm not sure there's going to be a single approach, honestly.
56:46
This has been fun, folks. I've really enjoyed this. Thank you very much for bringing it together. And some tough and some interesting and fun questions. And for the whole day, actually, thank you, everyone who's been involved with arranging it. I just turned up and talked about stuff and I really enjoyed it.
57:01
So thanks, everyone. It's been really interesting talks that I've listened to as well. So thank you. Very interesting thing. I feel participants to ask questions and got involved and stuff. So I would certainly like to thank them from my point of view. Common. Yeah. Come and look at the companies in the organizations we're involved with, the research that everyone's doing.
57:20
You know, I'm sure all of us would like to talk to you more. All participants on this. So, yeah. Get in touch, please. Thanks to all the speakers and indeed the participants. And let's all hope we can see each other live next year in Brussels. That would be really cool. It would be very good. So, yeah, it's hard to hope for it. But let's let's hope. Do we have permission to go and have a beer now? Is that is that acceptable from the organizers?
57:47
Yes, surely. Thanks for the input. I think you should have a beer after such a long day. Thank you. Thank you very much. See you next year. Thanks. See you.
58:02
Thank you all. A very interesting discussion.