Rethinking the OS for Isolation Flexibility with FlexOS
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/57118 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2022219 / 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
Information securityFlow separationKernel (computing)Plane (geometry)Decision theoryAreaCodeMathematical optimizationArchitectureComputer hardwarePatch (Unix)Point (geometry)Physical systemComputer networkDevice driverLibrary (computing)AbstractionMechanism designComputer-generated imageryIntelConfiguration spaceChainoutputFront and back endsModul <Datentyp>Core dumpIndependence (probability theory)System callImplementationMechanism designComputer hardwareLibrary (computing)Data structureKernel (computing)Operating systemFlow separationPatch (Unix)Physical systemConnectivity (graph theory)TwitterIndependence (probability theory)RewritingSystem callMultiplication signSimilarity (geometry)ChainTask (computing)ImplementationSoftwareResultantPoint (geometry)Cartesian coordinate systemAxiom of choiceChemical equationFront and back endsMereologyPoint cloudCategory of beingInformation securityMedical imagingProjective planeState observerMikrokernelVulnerability (computing)Single-precision floating-point formatMaxima and minimaMathematicsStrategy gameOperator (mathematics)Virtual machineProcess (computing)Computer architectureSpeicherschutzWeb pageAbstractionoutputInterface (computing)Film editingProcedural programmingCASE <Informatik>Slide ruleSoftware maintenanceFree variables and bound variablesLogic gateSpacetimeSeitentabellePerturbation theoryBitSet (mathematics)Operating systemStack (abstract data type)CodeKey (cryptography)Boundary value problemDifferent (Kate Ryan album)Primitive (album)BuildingRange (statistics)Functional (mathematics)Domain nameGroup actionConfiguration spaceTheoryComputer fileInternet service providerEngineering drawingComputer animation
08:35
PrototypeImplementationFront and back endsIntelFile systemComputer networkScheduling (computing)Server (computing)Library (computing)Standard deviationComputer-generated imagerySubsetAverageQueue (abstract data type)GradientSmoothingSimilarity (geometry)TelecommunicationWeb pageMechanism designOverhead (computing)EmulationPairwise comparisonDecision theoryInformation securityComputer hardwareMassConfiguration spaceResultantInsertion lossMultiplication signNumber2 (number)Front and back endsQuery languageDifferent (Kate Ryan album)SoftwareMechanism designWeb pageOverhead (computing)Pairwise comparisonSpacetimeLibrary (computing)Total S.A.Set (mathematics)MereologyStack (abstract data type)TelecommunicationDomain nameFreewareScheduling (computing)Computer fileMeasurementCartesian coordinate systemSemiconductor memoryStandard deviationGraph coloringCategory of beingFree variables and bound variablesFunctional (mathematics)Key (cryptography)ImplementationUniform resource locatorLogic gateSpeicherschutzRun time (program lifecycle phase)Source codePoint (geometry)Normal (geometry)PrototypePresentation of a groupPerformance appraisalMemory managementOnline chatVulnerability (computing)Group actionOcean currentDecision theoryExtreme programmingComputing platformState observerServer (computing)Medical imagingKernel (computing)Computer hardwareAddress spaceGreatest elementBenchmarkIntegrated development environmentComputer animation
17:00
Computer architectureComputer animationMeeting/Interview
17:25
Meeting/Interview
17:50
Software testingMeeting/Interview
18:22
Software testingMeeting/Interview
18:56
Remote procedure callLatent heatAreaCodePrimitive (album)Semiconductor memorySoftware developerMechanism designFront and back endsTelecommunicationCASE <Informatik>Logic gateAbstractionType theoryVariable (mathematics)Meeting/Interview
20:40
Set (mathematics)ImplementationPointer (computer programming)Front and back endsMeeting/Interview
21:02
Parameter (computer programming)Mechanism designCASE <Informatik>Library (computing)Range (statistics)Web pageDifferent (Kate Ryan album)Online chatAbstractionPointer (computer programming)Domain nameAddress spacePoint (geometry)Meeting/Interview
22:34
Computer hardwareLibrary (computing)Meeting/Interview
22:58
CASE <Informatik>Term (mathematics)Line (geometry)Meeting/Interview
23:18
Engineering drawing
23:54
Computer animation
Transcript: English(auto-generated)
00:10
Hello, first of all, I'm Hugo Le Fevre, PhD candidate at the University of Manchester, and debuting developer. I'm going to present the result of my research on OS design over the past two years, how I
00:22
try to rethink the operating system for isolation flexibility. This project is called Flex OS. On the academic side, it has been published at Hot OS early last year, and more recently at Asplos. This is the result of a cooperation between the University of Manchester, Polytechnic at Bucharest, and NEC Laboratories, Europe.
00:44
Let's get started. So if we take a look at current OS designs, it is quite clear that security or isolation strategies are typically fixed at design time. Taking the example of a typical monolithic operating system, such as Linux, there is a user kernel separation
01:01
and the process abstraction using the page table. This is quite set in stone. You can make similar observations for other OS designs, such as microkernels or single address-based operating systems. And the result of this is an understanding of the operating system that does not work very well with modern specialization or hardware
01:24
heterogeneity trends. For example, if you want to remove the user kernel separation in Linux, you might want to do that for performance reasons, as part of the unikernel trend. But it would require major rewrites. You would have similar issues if you
01:41
try to use hardware capabilities, such as Cherry, or memory protection keys, instead of the page table. That's also very much in the spirit of the times. And most would agree with me that this is no simple task with major rewrite and maintenance ahead. With XOS, we propose to take a different approach
02:02
and decouple security or isolation mechanisms from the design of the operating system in the first place. The goal is to be able to achieve a range of trade-offs instead of a single point in the design space. We aim to support a range of isolation mechanisms, hardware
02:23
and software, and granularities. In essence, what we want to do is to specialize the operating system for security for given use cases. Now, other use cases that we envision for flexible isolation includes, besides pure specialization,
02:42
the deployment, for example, to heterogeneous hardware. Here, we are envisioning to make use of each machine's or architecture's mechanisms optimally with minimal code changes. Another one would be to quickly isolate vulnerable libraries. Let's say vulnerability is found in one of the libraries you're using.
03:00
You can quickly and easily apply fine-grained protections to at least mitigate it while a patch is being developed. Finally, we envision to use isolation flexibility to guarantee that the properties of certain verified or safe components in a system hold while being mixed and matched with unsafe components.
03:26
So now that I'm motivated for isolation flexibility a little bit, let me try to summarize the spirit and the scope of this project in four simple points. So first, we focus on single-purpose appliances
03:41
like cloud microservices. So no desktop operating system, no general-purpose operating system. And the point here is that we are advocating for specialization of the operating system towards the application it's running. That starts to make much less sense when several of them are running.
04:01
Second, we advocate for a holistic approach to compartmentalization. Instead of considering only the application or only the kernel, we want to have everything on the balance to make the best choices performance and security-wise. Once again, we want to specialize.
04:21
Fundamentally, what we do is embracing the library operating system philosophy. And so all system components are libraries and all libraries should be equal before the hardware. Third, we want to abstract away the details of isolation mechanisms.
04:40
You know, the page table, Intel memory protection keys, a tease. They surely don't have the same guarantees but conceptually they have a lot in common and we can unify them behind a common interface, the isolation mechanism structure. And finally, we think that flexibility must not come into the way of performance.
05:02
And the question is, can we achieve a new layer of abstraction at nearly zero cost? Now, all of this is theory. So let's take a look at the concrete stuff we built. And let's start with a 10,000 feet overview of FlexOS. So first, users would come
05:20
with a simple configuration file describing the system that they want to build. And therefore they would select an application, libraries, boundaries, and safety mechanisms. Following this, the tool chain would select an isolation backend that is going to provide safety primitives for the system.
05:42
So isolation backends can leverage software as well as hardware-based technologies such as memory protection keys or even VMs. Then the tool chain would automatically rewrite the application and libraries to match requested properties. Following this, with this backend
06:01
and rewritten libraries in hand, the tool chain will be able to generate an appropriate image. So these points here might still be somewhat confusing for you. And that's where the new abstraction comes into play. So let me speak a little bit more about it and I hope that it will become more clear.
06:21
So as I was mentioning earlier, FlexOS embraces the philosophy of library operating system. And so it's quite naturally that we decided to base it on UNIcraft. And the gist of library operating systems like UNIcraft is really that they are composed of a set of fine granular independent libraries assembled together at compile time.
06:43
In FlexOS, we take that idea and start considering these libraries as finest unit of compartmentalization. They're great for that because they have naturally well-defined interfaces with a clear cut on shared data. What we fundamentally rethink, however,
07:01
is how these libraries communicate. As part of reporting phase, we are going to pre-compartmentalize them. Fundamentally, what we do is we modify them to replace cross-library procedure calls and share data by an abstract construct that we call gates and data sharing primitives.
07:21
And we define them as part of the FlexOS API. So we will see how to do that concretely in the next slide. Finally, at build time and based on the user's input that we saw previously, these abstract construct are going to be replaced by the tool chain with a concrete implementation.
07:42
For example, you could take a procedure called simple function call for isolation for no isolation boundary. And you could take MPK or T domain transitions or even different VMs if you want to go crazy to add isolation boundaries. So now let's become even more concrete
08:03
and let's take a closer look at the API. This example, we're going to consider a simple call to receive from the application and receive is implemented in the network stack. As part of the porting process, we would annotate share data first
08:20
and add gate placeholders. Then at build time, if the application and the network stack are in two different compartments and we're using MPK to isolate them, then we would replace the annotated share data with a shared heap location
08:42
and the gate placeholder with an MPK gate. That would be very different if we decided to put the application and the network stack in the same compartment. In that case, we would replace the annotated share data with a normal stacker location. No need to do anything fancy here in the same compartment.
09:01
And we would replace the gate placeholder with a simple function called, once again, when the same compartments and no need to do anything particular. So we not enter too much into backend details here for time reasons, but there are more in the paper. So you're welcome to take a look at it. So we built a prototype of XOS.
09:23
The implementation, as mentioned earlier, is based on UniCraft. We have developed backend implementations for Intel memory protection keys and different VMs. In the VM case, we basically put each compartment in its own VM and they communicate via inter-VM shared memory.
09:43
So we have also ported libraries to run as isolated libraries. So the network stack, the scheduler file system, the time subsystem, they're good examples. And we also have application support for Redis, Nginx, SQLite, and the hyper server.
10:02
In this talk, I am going to focus on demonstrating flexibility and performance, but there are more measurements in our papers. You're welcome to take a look at it. So the first part that we'll take a look at it, that's right. The first part we'll take a look at now is quite complex.
10:21
So I will try to slowly introduce it. What we want to do here is to demonstrate the flexibility of XOS or the design space that we can achieve. We're gonna measure the runtime performance with Redis in request per second. At the bottom,
10:41
you have the different configurations that we're going to invite to evaluate. The four items here are flexible libraries used in the Redis image. So only a subset for readability. At the top, the Redis application, then the C standard library, the scheduler and the network stack.
11:04
Each bar represents one configuration and its associated performance. We have 80 configurations in total. The way you can read the configurations at the bottom is the color indicates the compartment. So white for compartment one,
11:20
red for compartment two, blue for three. If you only have white for your board, there is only one compartment, so no isolation. And the dot tells you what they're hardening. So the address in it is a safe stack. UBSan is enabled. So the first observation that we can make here
11:41
is that we have a pretty large gap between the most expensive and the least expensive configuration. And the configurations at extremes are roughly what we expect them to be, full on and full off. We can also see that the slope is pretty smooth.
12:02
Basically, if you give me a performance price that you're ready to pay, I can give you a configuration that's pretty much exactly what you're asking for. The most interesting thing, however, is that you sometimes can get very different properties at pretty much the same cost.
12:21
And most of the time, that's due to the way libraries communicate. Take the example on the right. Security-wise, they're very different. On the left, you have three compartments, the network stack and the scheduler in different compartments. And on the right, you have two compartments,
12:41
the network stack and the scheduler in the same compartment. So security-wise, they're different. But performance-wise, they're very, very close or identical. That's because the way the network stack communicates with the scheduler goes through another compartment, another library that is always
13:02
in the third or the second compartment. And so in both cases, you have two domain crossings. And so you have the same cost. So clearly you can get some safety for free by exploring intelligently. And that's something we explore in greater detail in the paper.
13:21
So there would be more to tell, but I hope that I could give you at least an idea in this limited time of the interesting things that we can do with isolation flexibility. The second set of results that we're going to take a look at is focused on performance and comparison with the baseline. Does flexibility come into the way of performance?
13:42
And here, we're going to take a look at numbers for SQLite, namely the time to perform 10,000 SQLite insert queries in seconds. So at the bottom, you have the number of compartments and the mechanism that's used. For example, PT2 for two compartments with the page table,
14:01
EPT2 for two compartments with VMs, MPK3 for three compartments with MPK and none for no isolation whatsoever. And at the top, you have the VMM or the environment we're running the benchmark in.
14:21
The first observation that we can make is that there is no overhead when disabling isolation in FlexOS. Basically, you only pay for what you get. So that's the first good thing. The second observation that you can make is that the MPK backend compares for positively to competing solutions.
14:42
The comparison with Capycalo OS is a bit tricky because they're using a Linux userland debug platform of UniCraft. But if you take relative numbers, it's still quite good for FlexOS. Finally, the PT backend compares to very positively to competing solutions.
15:02
Here, we would make a comparison with Linux. It's interesting to see that we get almost the same number as Linux. And the fact is, it's more clear in the paper, the domain transition cost between userland and kernel is actually very similar to the communication cost
15:22
between different VMs and the EPDKs. So as a conclusion, I highlighted the need for more isolation flexibility, whether it is for specialization purposes to adapt to new hardware or simply to clearly react to newly published vulnerabilities.
15:42
Current approaches tend to take one approach at design time, and that makes them effectively representing a single point in the design space. In this work, I presented FlexOS, an OS that decouples isolation from the OS design, effectively making isolation decisions at build time.
16:03
I presented some of our results that motivated for more automatic exploration of the new trade of space, something that we do in greater detail in the paper. So if you're interested in this work, you're welcome to come have a chat. Good starting points would be our website,
16:22
the preprint of the paper, and of course, the source code that's released under BSD3. We're proud to say that this work is reproducible research. All results presented in this presentation have been artifact evaluated by the S-PLOS artifact evaluation committee.
16:41
And finally, I want to stress how much of a team effort FlexOS is. Nothing that I presented in this presentation would be there without my colleagues from Manchester, UPB, and NEC. And I'm really happy to take questions and have a discussion.
17:00
Thank you. Informed if he tries to compile an API to an architecture that just doesn't support all the features that are required.
17:22
So basically- I think you're muted. I'm not supposed- I cannot hear you. Huh.
17:41
That is annoying. Does this work? I hear you on the main channel. So can you actually hear me or not?
18:03
Because I don't know what is going on, supposed to be working. Test, test. Can you hear me? No? Okay, so should I-
18:21
I hear you with a lot of delay. There's like one minute delay. Oh, wow. Okay, so I'm maybe just gonna try to answer the question and there will be delay unfortunately, but- Test, test. Now I hear you. Okay.
18:50
So what should I mute? Because I only have this open, so. You can hear me. Okay. So is it on John's side, the issue?
19:02
Probably so. Okay. I'm just gonna try and answer the question. So basically what we try to do is to create a layer of abstraction that is going to sit in front of the isolation mechanism.
19:21
We call it the backend. So we have this compartmentalization API that you use to port the code. And on the other side, developers are going to write backends that implement support for a specific isolation primitive. If I take the example of what we implemented,
19:43
NPK, in this case, the developers are going to implement the gates by changing the value of the PKRU. They are going to map the shared variables to areas of shared memory.
20:01
In the case of VMs, developers are going to map gates to RPC to inter-VM communication like remote procedure calls. They're going to use a shared memory as well. And you can actually map this quite well
20:21
to Cherry as well. In this case, you would have gates that if you take the century type of yeah, okay, maybe I shouldn't go too much into that. Is this with pure capability code
20:41
or with native capability code? Yeah, exactly. You can have this set of capabilities that take care of doing this transition, I guess. Which of them did you use? Did you use native or hybrid or pure? So basically at this stage, we didn't implement support for Cherry backend.
21:01
Because, well, you can just simply pass a pointer from one place to another one because if you pass it via capability, you need to use the capability of instructions, which actually means that you need to rewrite the entire code. Well, this is the problem. There is a question in the chat. So you proposed an abstraction that abstracts different isolation,
21:21
inter-process isolation technologies like MPK, will Cherry in some extent. And definitely this technology has different granularity, have different MPKs, has a basic granularity. Cherry ideally can be byte addressable. So why do you think it's a good abstraction?
21:41
So at some point you have to decide of a base granularity of a minimal granularity if you want to be able to have this abstraction that can be applied to a wide range of mechanisms. The basic granularity that we decided to go for
22:02
is the library. Speaking about arguments of a call, so when you pass an argument of a call, for example, a pointer to a buffer, this often should be aligned and should be alone inside the page because you use MPK pages to remap this page from one protection domain to another one. While in the case of Cherry,
22:21
well, you don't need to remap the entire page because you can deal with bytes. So the abstraction you use actually quite different in the case of those two different technologies. Yeah, well, I'm pretty sure that you could actually write the backend in such a way that you take advantage
22:40
of the hardware's abilities. For sure, if you want to isolate at a granularity that's finer than your library, you will need to split the library manually. Okay, so another question, how much important effort is required to use your system?
23:03
Okay, so in the case of Redis, we actually put that in the paper. In the case of Redis, that was about two days, I think. In terms of lines of code, it's a few hundreds.