CloudABI: Capability based security on Linux/Unix
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 | ||
| Part Number | 28 | |
| Number of Parts | 169 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/21087 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EuroPython 201628 / 169
1
5
6
7
10
11
12
13
18
20
24
26
29
30
31
32
33
36
39
41
44
48
51
52
53
59
60
62
68
69
71
79
82
83
84
85
90
91
98
99
101
102
106
110
113
114
115
118
122
123
124
125
132
133
135
136
137
140
143
144
145
147
148
149
151
153
154
155
156
158
162
163
166
167
169
00:00
Information security1 (number)Information securityFormal grammarContent (media)Cycle (graph theory)Line (geometry)RoboticsLecture/Conference
00:48
Insertion lossCycle (graph theory)Data miningMereologyInheritance (object-oriented programming)Source code
01:38
TelecommunicationMusical ensembleTelecommunicationDivisorMusical ensembleSynchronizationMultiplication signIncidence algebraWave packetLecture/ConferenceComputer animation
02:14
2 (number)Fiber (mathematics)Food energyMotion captureCASE <Informatik>KinematicsLecture/ConferencePanel painting
02:58
Data miningMultiplication signPosition operatorDivisorNatural numberLecture/Conference
03:32
Charge carrierCharge carrierMotion captureExecution unitPlanningRule of inferencePhysical systemExistenceOperating systemIntelComputer animation
04:30
WordEmailCommunications protocolBell and HowellPhysical systemComputer virusCodeSoftware developerWeightLecture/Conference
04:58
Computer virusPrimitive (album)Field (computer science)Replication (computing)Charge carrierFamilyComputer animation
05:37
CausalityMathematical analysisRootCausalityRootField (computer science)Constructor (object-oriented programming)Decision theoryProcedural programmingMathematical analysisLecture/Conference
06:15
RootCausalityMathematical analysisComputer fileOrder (biology)Buffer overflowComputer architectureTrojanisches Pferd <Informatik>Table (information)WeightTraffic reportingSocket-SchnittstelleLecture/Conference
07:06
ArchitectureZugriffskontrolleComputer architectureGame controllerBoiling pointPhysical systemComputer programSoftware testingDefault (computer science)Integrated development environmentData structureState of matterOperating systemInformation securityLecture/Conference
08:09
System administratorRevision controlExecution unitReverse engineeringPhysical systemScaling (geometry)Lecture/Conference
08:45
Information securityComputer programClient (computing)Semiconductor memoryPoint cloudResultantBinary codeStaff (military)Thread (computing)Befehlsprozessor
09:53
Process (computing)ResultantVirtual machineOperating systemDerivation (linguistics)Functional (mathematics)Level (video gaming)MultiplicationBitPoint cloudProjective planeHuman migrationInformation securityFreewareSystem callSpherical capWeightLecture/Conference
11:31
Information securitySystem callLibrary (computing)Projective planePseudozufallszahlenProcess (computing)Phase transitionComputer fileRun time (program lifecycle phase)
12:02
Computer filePoint cloudSystem callProcess (computing)DatabasePrincipal ideal domainDefault (computer science)Physical systemLecture/Conference
12:44
Process (computing)File systemComputer fileBuffer overflowZustandsgrößePoint cloud1 (number)Functional (mathematics)Operator (mathematics)Buffer solutionCategory of beingExterior algebraStatisticsSound effectSoftware bug2 (number)Thread (computing)Operating systemObject (grammar)JSON
13:53
Standard errorExterior algebraComputer programStandard deviationPoint cloudParameter (computer programming)Message passingProcess (computing)Lecture/ConferenceJSON
14:32
Token ringComputer fileString (computer science)Process (computing)Token ringComputer fileDirectory serviceNetwork socketPoint cloudLecture/ConferenceComputer animation
15:23
Single-precision floating-point formatComputer fileToken ringInterface (computing)Cartesian coordinate systemSingle-precision floating-point formatProcess (computing)Binary codePhysical systemCompilerLecture/ConferenceComputer animation
15:57
FingerprintLevel (video gaming)Physical systemFreewareArithmetic progressionCASE <Informatik>Point (geometry)Lecture/Conference
16:34
Scripting languageDifferent (Kate Ryan album)MereologyUtility softwareMessage passingSource codeContent (media)Endliche ModelltheorieoutputComputer fileOperating systemStandard deviationDirectory serviceSingle-precision floating-point formatProcess (computing)Mathematical analysisString (computer science)Computer programNumberRead-only memoryElectronic mailing listResultantSystem callOperator (mathematics)Open sourceExact sequenceSource codeJSON
18:52
Point cloudComputer programMechanism designPhysical systemSequenceSet (mathematics)Functional (mathematics)Computer fileMappingoutputFunction (mathematics)Descriptive statisticsContent (media)Electronic mailing listScripting languageProcess (computing)Online helpError messageSingle-precision floating-point formatStandard errorLevel (video gaming)Network topologyStructured programmingResultantOpen setKey (cryptography)Data structureLecture/ConferenceSource codeJSON
20:41
Open sourceComputer programoutputPoint (geometry)HypothesisPoint cloudArithmetic progressionMoment (mathematics)Lecture/Conference
21:33
World Wide Web ConsortiumServer (computing)Web 2.0Server (computing)Computer fileSoftwareContent (media)Configuration spaceString (computer science)Network socketParameter (computer programming)Moment (mathematics)Order (biology)Point cloudStreaming mediaOnline helpJSON
22:49
Service (economics)SoftwareSoftwarePoint cloudPlug-in (computing)Physical systemLimit setOperating systemEntire functionComputer fileLecture/Conference
23:20
SoftwareService (economics)Vulnerability (computing)Physical systemCloud computingGoogle App EngineResultantLibrary (computing)Assembly languageVirtual machineCartesian coordinate systemOverhead (computing)outputComputer programFormal languageTheoryMedical imagingOrder (biology)Videoconferencing3 (number)VirtualizationLecture/Conference
24:51
Chi-squared distributionComputer fileDirectory serviceComputer-assisted translationProgrammable read-only memoryBinary fileInstallation artOrdinary differential equationLetterpress printingDegree (graph theory)Natural languageTouchscreenSharewarePhysical systemOnline helpPressureKey (cryptography)Computer fileBinary codeRevision controlComputer programGodContent (media)Order (biology)EmailFunction (mathematics)Moment (mathematics)Arithmetic progressionParameter (computer programming)Combinational logicSubsetStandard deviationMultiplication signoutputRight anglePoint cloudClient (computing)Lecture/ConferenceComputer animation
27:18
Arc (geometry)Computer-assisted translationLibrary (computing)System callStandard errorLibrary (computing)Process (computing)Binary codeResultantOrder (biology)Standard deviationBefehlsprozessorRight anglePhysical systemContent (media)Read-only memoryCASE <Informatik>Scripting languageComputer fileLecture/ConferenceComputer animation
28:38
Open sourceEvent horizonInformationAddress spacePoint cloudSoftwarePhysical systemTap (transformer)Forcing (mathematics)Lecture/Conference
29:19
System administratorSoftware developerMultiplicationMereologyExecution unitUniverse (mathematics)Physical systemMultiplication signNumberFrequencyINTEGRALDistribution (mathematics)Moment (mathematics)Repository (publishing)Information securitySoftwareProduct (business)Configuration spaceBinary codeSynchronizationLevel (video gaming)Computer programCycle (graph theory)ResultantProcess (computing)Shared memoryLibrary (computing)NeuroinformatikInheritance (object-oriented programming)Pattern languageOverhead (computing)Element (mathematics)Focus (optics)Operating systemMobile appSubsetPoint cloudPhase transitionCuboidOrbitFreewareLecture/Conference
34:45
Degree (graph theory)Graph (mathematics)SequelPulse (signal processing)CAN busRing (mathematics)Revision controlSpecial unitary groupWeightLaceBranch (computer science)Maxima and minimaArmScalable Coherent InterfaceGrand Unified TheoryRun time (program lifecycle phase)CuboidEndliche ModelltheorieSoftwareOrder (biology)Interactive televisionBinary codeSoftware developerComputer fileProcess (computing)DemonGastropod shellSource codeProgram flowchartLecture/Conference
35:36
Point cloudLink (knot theory)Lecture/Conference
Transcript: English(auto-generated)
00:00
This is Cloud ABI talk. Just make sure you're the right ones. Yeah, so we have Alex Warmer speaking to us about the securities on Linux.
00:23
Greetings, everyone. Thank you for coming to this briefing on the inquiry into the Sol 3 defeat 20 cycles ago. Contents of this briefing are classified Duchess Royal Budline. Anybody who does not have that classification must leave the room now.
00:40
Okay, with the formalities over, we can begin. My name is Alex Wilmer. My mother was Susan Wilmer. She was chief of docking during the Sol 3 harvest 20 cycles ago. It was her that allowed that fateful ship to dock, scout ship TLV 3495,
01:02
the one that we'd presumed destroyed aeons ago. This was the ship that was carrying two human cable repair engineers. Those cable repair engineers were carrying their Jolly Roger super weapon.
01:21
That led to the destruction of the entire fleet and the loss of the Sol 3 harvest along with nearly a billion mines. I've been part of the team for the last 15 cycles investigating the reasons for this defeat. There were many contributing factors.
01:43
Our synchronization signal impinged on human communication bands. They were able to detect this and from this calculate the time of harvest. This resulted in their human leaders surviving the initial harvest attack.
02:06
There were numerous smaller incidents such as trainee GX firing on a human welcome wagon. We've seen such attacks, we've seen such attempts to communicate before.
02:21
They've of course never been successful. But in this case, critical seconds were lost in confusing the humans and they were able to escape the initial fireball. Another example I would like to highlight, following the initial counter attack by the humans
02:42
which was of course futile. Their kinetic weapons, their missiles could not penetrate our energy based shields. But in one case, a downed ship did lead to the capture of the pilot. The pilot was taken to the human leaderships
03:02
where a pilot was tortured, interrogated, mine probed. During this, the pilot did reveal our negotiating position, our harvest tactics and our general disposition. This resulted in counter attacks by the humans of a thermonuclear nature.
03:23
Of course, this was a still futile. But they were contributing factors. Finally, there was one more that I'd like to highlight. The captured craft was not challenged, was not questioned when it approached
03:45
our main harvest ship. This allowed it to gain access to the command carrier. This allowed the humans to gather intel on our initial invasion plans. All of these pale insignificance
04:06
to the principle reason for the Sol III defeat. Capture of the scout ship. From this capture, the humans learned of our existence. They learned of our biology. They learned of our technology.
04:22
Critically, they learned of our Unix operating system. From this unit, from our technology, the humans went on to develop various things. Human code words include Roswell, Area 51, Unix, Bell Labs, ARPANET, AOL, email.
04:44
All of these are pale imitations to our consensus net, of course. But they gave the humans a critical foothold into our protocols and systems that allowed them to upload a virus to Reclamation Pump 369282.
05:06
That replication pump then communicated on consensus net, spread, sent commands fleet-wide, resulting in the disabling of all protection fields.
05:24
From this, the humans were then able to use one of their primitive thermonuclear devices, destroying our carrier ship. Our thoughts, of course, go to all the families of those aboard.
05:41
So for the past 15 years, we have been carrying out the investigation. There are numerous lessons that have been made in procedure and command decisions. This briefing will concentrate on some of the technological implications. We find that the root cause analysis pump mon,
06:00
running on that pump, was vulnerable to the human's attack. That is how they got their foothold. That is how they were able to instruct all defense fields to switch off. Without that, their attack would have been useless.
06:21
The problem with pump mon was not a simple buffer overflow or stack smashing attack. The problem was more architectural. Pump mon had numerous capabilities that it did not need in order to fill the role of monitoring that pump. It could read global files.
06:42
It could monitor processes. It could create network sockets to other places on consensus net. All of these were unnecessary and all of these were exploited by the human Trojan.
07:00
The table you see is a quote from the report. Please refer to that if you need the full details. So the architectural flaws of Unix boil down to discretionary access control. That is, access control is not enforced
07:21
by default. There are things that are open that do not need authenticated access. This means that programs on Unix systems start with excessive capabilities. And once compromised, programs can acquire further capabilities simply by opening them.
07:41
There are global resources and global states throughout the Unix system. This obstructs running programs securely. It obstructs writing testable programs because tests have to try and inject these normally global resources inside a restricted test environment.
08:02
It obstructs writing reusable programs because these programs assume a full Unix operating system and it is very difficult to audit them to say what do they actually use. System administration just does not work at harvest fleet scale.
08:21
Beyond a million nodes, we just do not know what these systems are doing. Our team would like to propose a human technology that has actually been adapted from their reverse engineered version of our Unix.
08:40
This human technology is called Cloud ABI. It is a relatively recent invention for the humans, approximately two years old. Under Cloud ABI, programs start with the ability only to spawn threads and to allocate memory. Unless they are provided with access to external resources,
09:05
they cannot access them. They cannot acquire further access to external resources. They can only do that through the capabilities
09:20
provided to them when they are started. The implications of this are it is safe to run an unknown Cloud ABI binary if it is given no resources. The worst thing that it can do is allocate too much memory and burn through CPU.
09:41
As a result of this, with explicit capabilities passed into the program at startup, it is much easier to audit these programs to say what they need. As a consequence, it is much easier to test these programs. This leads to better release engineering and could allow for higher level orchestration,
10:03
the ability to migrate processes between hosts rather than virtual machines or containers. This could lead to more efficient resource use in fleets and certainly to more secure resource use.
10:21
To give you a bit of background on this Cloud ABI technology, it was initially developed by a human called Ed Schouten. He is located in the European continent. It was initially for the human derivative of our Unix called FreeBSD.
10:42
It is now available for multiple human operating systems and is compatible with our SenseNet and original Unix. Some of you may be familiar with a human technology called Capsicum. Cloud ABI is derived from this Capsicum project.
11:02
In Capsicum, processes initially gain access to global resources and can acquire further resources just like any other Unix process. But a Capsicum process can call a function called capenter, after which syscalls that allow it
11:20
to acquire further resources are blocked. They return an error and or result in the process being killed. This allows for more secure processes after they've left their initial startup phase. The problem with this Capsicum project is that integrating external library
11:43
into a Capsicum process causes runtime errors, strange behaviors, Heisenbugs, because a library buried deep in the call stack might try to open a file, might try to initialize a pseudo-random number generator
12:04
from a device and then fail and fall back to a less secure method such as the time of day or the current PID. The innovation that Cloud ABI takes is to make Capsicum default. It is always on.
12:21
Cloud ABI processes cannot call open. They cannot see global resources such as process tables, file systems, or user databases unless explicitly given access.
12:41
To give you an idea of what we remove, all of these APIs are unavailable to a Cloud ABI process. The first category is simple common sense. These are APIs that were not greatly designed in the first place or they tend to result in,
13:05
they tend to result in buffer overflow bugs. There are thread safe, buffer safe alternatives already available for both Unix and Cloud ABI. The second category is basically the Unix file system.
13:22
On a Unix operating system, a process can open or attempt to open any file by its path. This is impossible in Cloud ABI. There is no open function. There is no stat function. There is no get PID, there is no get UID.
13:43
Next we move on to mutable state functions. These are ones that tend to have an effect process wide regardless of whether a process is multi-threaded. These are removed because they make programs harder to reason about.
14:02
Removing them simplifies the API and there are thread safe alternatives. Standard in, standard out, and standard error are also removed simply because they are a global resource that should be explicitly declared.
14:24
ARGV is also removed. The method of passing in arguments to a Cloud ABI process is incompatible with ARGV, which relies on acquiring resources based on string values.
14:42
This is disallowed. After removing these things, we add one simple concept. Unix file descriptors become capability tokens. These are the tokens by which
15:03
a Cloud ABI process acquires all resources. All APIs in Cloud ABI that allow acquisition of new resources require an existing file descriptor to be passed in. A file descriptor might describe a directory,
15:22
a file, a socket, or even the handle to control a sub-process. The second thing we add is a single application binary interface. This means that a Cloud ABI process,
15:40
once compiled on any Unix system, native or human, will run on any other Unix system without recompilation. The ABI is available for the following human systems, FreeBSD, Arch Linux, Debian, Ubuntu.
16:03
It is even available for their Mac OS. The support is in progress on the Linuxes, but with the next release of the human's FreeBSD, it will be a native feature.
16:25
So, it's best at this point to illustrate with an example. We'll be taking a very simple, naughty case of a Unix utility, ls. This takes the name or the path of a directory
16:43
and prints out the names of the files and folders inside it. This is a very simple example, stripped down to illustrate our differences. You will note that the process is taking in a string and assigning it to the variable der path.
17:03
It is then passing this string down to the operating system, and the operating system is acquiring resources on behalf of the process. If we did not see the source code of this process, we do not know what it would be capable of. It might list the directory,
17:21
it might list the directory, and send those results back to the humans for further analysis. It might encrypt the contents of the directory, it might delete them. It could do any number of things we don't know without fully auditing the source code. Using some of the features of Unix,
17:43
we can come closer to a Cloud ABI design. In this one, the ls program does not take any string input. It receives only file descriptors. File descriptor zero is the directory that we are trying to show the contents of.
18:03
File descriptor one happens to be standard out. Given this model, if the program was unable to pass strings to the call to open and the call to list der,
18:23
we could say that this process was not able to do anything other than act on the resources we provided. Namely, read-only access to a single directory and everything below, and write-only access to a single file string.
18:43
Namely, set standard out. The problem with this model is that it becomes very inflexible to pass in file descriptors in the exact sequence that they will be used by the program. So, the Cloud ABI system
19:01
relies on a new mechanism called arg data. In arg data, there are a set of APIs to gather file descriptors according to a tree structure. Programs can acquire these by key name
19:21
as lists of file descriptors or maps. In the example you see, we use a helper program called Cloud ABI Run to map a YAML file containing a description of the input to the program
19:41
to the file descriptors that the program will receive. In this example, the Python executable is not a Unix executable, it is a Cloud ABI executable. Therefore, during the build of this Python executable, any reference to standard in, standard out, standard error,
20:04
the C level function open, the C level function stat, the C level function open dir would have resulted in compile time errors. As a result, we can safely say that this execution of this Python script
20:23
cannot do anything except read the contents of a single directory and write the output to a single file descriptor. This makes this process safe to execute
20:41
without trusting its source. We need only know that we have exposed the inputs we provide to that program. The inputs are explicit, not implicit. A further example, it should be mentioned at this point
21:01
that this example is, at the moment, hypothetical. The Python port to Cloud ABI is in progress. It cannot currently do this. Other programs written in other C programs
21:21
are fully ported and there is a Cloud ABI ports set of packages available. To give you a further example of illustrating what might be possible, we show here a example configuration for a web server.
21:41
The web server binary itself would not have its own configuration file. It could not read that file unless provided and that file would contain strings referring to paths which the web server would not be able to open. So in this example, we combine arguments
22:00
and configuration into a single file and this file is provided to the Cloud ABI run helper in order to acquire resources on behalf of the web server. Where this web server compromised, it could not start listening on new ports. It could not open a network connection
22:20
to send the contents of any acquired data out to the world. All it could do is serve network traffic on the socket that we have provided.
22:41
So at this moment, what is, so at this moment we ask what can we do in the future with this Cloud ABI system? We might imagine a future where software appliances can safely run customer provided plugins
23:04
or third party plugins without exposing the internals of their system or the entire operating system. These plugins will be provided with a limited set of file descriptors and would therefore be constrained in what they could do to affect the outside world.
23:23
We might use this to isolate, isolate, vulnerability, vulnerable systems such as Pumpmon or transcoding libraries for security cameras from fleet-wide security systems.
23:41
By this means we could avoid problems in error-prone libraries such as the human library ImageMagick or the various video encoding libraries that have extremely complex input requirements and as a result tend to have many vulnerabilities found.
24:04
We might imagine the ability to use Cloud ABI in order to implement the human system Amazon EC2 without the overhead of virtual machines or containers. Similarly we might imagine the human system Google App Engine
24:22
with the ability to submit programs written in any language, C, C++, Rust, Assembly language. In theory these would be safe languages to implement programs in and allow them to be uploaded to a third-party cloud service without virtualization.
24:45
This would allow us to compose applications, not containers. I shall now show you a brief demo of what has been achieved with the human language Python
25:02
and the Cloud ABI system. Of course it would help if I showed this on the right screen.
25:24
In order to run a Cloud ABI program on this system we can use the Cloud ABI run helper.
25:41
The Python binary you see has been compiled against the Cloud ABI system headers and version of libc. The Python binary itself cannot accept standard input
26:00
or write to standard output. So the file that we are providing is going to the Cloud ABI run program which is a Unix program. It is opening resources on behalf of the Python binary. The Python binary is then receiving file descriptors.
26:28
The demo gods.
26:49
So the contents of that YAML file look like this. At the moment the Python binary is a work in progress.
27:02
This is the first thing that got working with it. We have transliterated the native Unix Python arguments into YAML keys and the command is given verbatim.
27:21
We are also able to execute some calls.
27:41
In this case the Python script, the Python binary are burning CPU and then printing the result out to standard error. As a result of Cloud ABI though this is the worst that this process can do. We can kill it and know that it has done no damage
28:03
to the system as a whole because it did not have access in order to do that damage. If we have a look at the contents of resource.yaml we see that all it had access to was read only access in order to import its standard library,
28:22
write only access to the standard error file descriptor and the ability to execute a simple syscall. Work will continue on the Python port
28:41
to the Cloud ABI system. There will be a sprint running at the human event EuroPython 2016 on Sunday. If you would like more information
29:02
please visit these addresses on the human network. Our usual network taps on their networks are in force. Thank you very much.
29:33
So we have some time for questions. Let's start with you and then I'll go with you.
29:42
Hi, I'm Yerny, thanks a lot for the talk. Hail the queen. Okay, awesome. So I'm wondering, you know, we have in the community like a lot of tools that attack the same problem.
30:00
We have AppArmor, we have things like OpenBSD and SA Linux from NSA, no back doors, I promise. So why another system? So the problem that we have found in our experience
30:24
with AppArmor, SA Linux, such systems is that the incentives with them tend to be wrong. It is not the creator of a piece of software that configures those systems. It is typically the distributors and the system administrators.
30:43
So as a result, the configuration of the protection system such as AppArmor or SA Linux tends not to be in sync with the requirements of the programs that are running. So all too often, administrators in the midst of battle
31:05
on a fleet ship will typically just turn them off. More so with inexperienced administrators but even seasoned veterans of multiple harvest campaigns
31:20
have been known to switch these systems off when there is incoming fire. Yes, okay, another question if I may? Okay, so is this thing production ready? What's the overhead and what is the biggest app you are currently running with it?
31:44
The system is still in its early phases. It was conceived approximately two Earth orbits ago, around two and a half cycles until the creator has been working on it quite a while
32:03
and is an experienced developer as humans go. The Python part of this is most certainly not production ready. It is, it would be tricky even to call it alpha.
32:24
Unfortunately, the human responsible for its development some inconsiderate human gave them a job. So there was not time to complete it before this briefing.
32:40
Hi, thanks for the talk. I'm curious about the support for binary libraries like BC box. Are they planned to be add to the Cloud API support? And we have seen a pattern command follow by humans
33:02
and they tend to use Linux a lot and avoid free BSD or the security focus tools. And we are also seeing a proliferation of a new tool called Docker who is taking a different approach to security.
33:23
It's the acceptance of Docker threatened the future of Cloud ABI. Are we investing time in Cloud ABI when we are going to face a different problem in the next harvest?
33:42
So I'm pleased to report that the next harvest fleet is on its way to Earth and they will pay for their treachery. The human technology Docker
34:00
provides similar benefits to Cloud ABI. It has slightly higher overhead and is restricted only to their Linux operating system. The Cloud ABI for Linux port is 90% complete. It lacks integration with their distributions at the moment.
34:22
We are working to improve this. What was the other part of your question please? Oh, so there is a repository available
34:45
of human derived software called Cloud ABI ports. Over 100 packages in this.
35:01
I do not believe that BusyBox is one of them. The Cloud ABI model is better suited to long running daemon processes than to interactive use. It can become quite unnatural, not unnatural.
35:22
It can be quite cumbersome in order to provide all the file descriptors to Cloud ABI binaries in interactive use in a shell. So that is possibly a development. If you wish to see if a package has been ported,
35:42
I recommend visiting the Cloud ABI ports link that was included in your notes. Any other questions? All right, thank you very much.