WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=OqM67QG_Ikk NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/OqM67QG_Ikk.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.480 --> 00:00:13.360 Welcome everyone. s3 00:00:13.360 --> 00:00:15.120 Can you guys hear me okay? s4 00:00:15.120 --> 00:00:20.080 I've been standing here for 15 minutes without saying anything, so we can start now. s5 00:00:20.080 --> 00:00:21.040 My name is Abhishek. s6 00:00:21.040 --> 00:00:25.040 I'm on the RL and agent infrastructure team at OpenAI. s7 00:00:25.040 --> 00:00:30.160 Um what that means is we work on the infra for reinforcement learning specifically. s8 00:00:30.160 --> 00:00:40.760 And on the product side, we also develop infra that helps run untrusted code as part of ChatGPT, Codex web securely and reliably at scale. s9 00:00:40.760 --> 00:00:45.680 This talk is called from fork to fleet, designing an agent sandbox cloud. s10 00:00:45.680 --> 00:00:53.680 Um I'll be very clear that there are a lot of words in the title that have OS and infra concepts, but this is a first principles talk. s11 00:00:53.680 --> 00:00:58.760 Uh so we'll cover what sandboxes are and why they are needed from first principles. s12 00:00:58.760 --> 00:01:06.960 We will also try to cover design intuitions around designing an agent sandbox uh cloud to run sandboxes securely and reliably at scale. s13 00:01:06.960 --> 00:01:10.520 So if if some of these words don't mean anything, don't be worried. s14 00:01:10.520 --> 00:01:14.840 We'll explain from first principles and and go from there. s15 00:01:15.800 --> 00:01:21.120 Uh last year I gave a talk talk called uh how to build an AI sandbox from scratch. s16 00:01:21.120 --> 00:01:24.840 Uh if if you're interested, you can uh look at that talk as well. s17 00:01:24.840 --> 00:01:30.160 Think of this as a spiritual sequel to that talk. s18 00:01:31.000 --> 00:01:31.400 Okay. s19 00:01:31.400 --> 00:01:34.360 So now let's forget about sandboxes or clouds for a second. s20 00:01:34.360 --> 00:01:36.240 Let's just go back in time. s21 00:01:36.240 --> 00:01:37.400 ChatGPT came out. s22 00:01:37.400 --> 00:01:39.920 It's a very large pre-trained model. s23 00:01:39.920 --> 00:01:45.840 Uh people ask all sorts of questions and it responds really really well, really really human-like answers. s24 00:01:45.840 --> 00:01:54.640 But when people ask questions like what is 3 + 3 or what how many hours in strawberry, sometimes it works and sometimes it doesn't. s25 00:01:54.640 --> 00:02:06.080 It answers questions like what is 3 + 3 quite well because it's trained on the entire internet and apparently people have written 3 + 3 equal to 6 many many times on the internet. s26 00:02:06.080 --> 00:02:14.040 So, it gets it right but people haven't asked how many hours in strawberry enough on the internet and so it gets it wrong. s27 00:02:14.040 --> 00:02:24.760 And so it's obvious that for anything code or math related or any problem which has a verifiable reward which means that it can be tested that it's true or false. s28 00:02:24.760 --> 00:02:39.800 The model needs something more and the key unlock was that given the model tool calling capability or a way to execute code the model gets these verifiable reward questions around code and math correctly. s29 00:02:39.800 --> 00:02:53.080 And that's from first principles came that if you give the models the ability to execute code it can hill climb and be very very good at math code and other domains that have verifiable rewards like cut to 2026 s30 00:02:53.080 --> 00:02:58.120 and we are seeing the the consequences of doing that at scale. s31 00:02:58.120 --> 00:03:04.239 So, now how can it answer what is 3 + 3 and how can it answer how many hours in strawberry? s32 00:03:04.239 --> 00:03:06.120 Well, it can write code to do this. s33 00:03:06.120 --> 00:03:21.680 So, if you see the diagram like we have a training loop and the training loop gives it tasks or questions and then the training and the harness then parses the response of the model and the response might say hey execute code on my behalf. s34 00:03:21.680 --> 00:03:33.920 The harness is responsible for executing the code and then a grader judges whether the answer is correct or not and then the training loop back drops and changes the weights and that's how we train it to do two things. s35 00:03:33.920 --> 00:03:44.400 We train it to call code execution or tools on certain classes of problems and secondly we ensure that the code it executes actually solves the problem. s36 00:03:44.400 --> 00:03:50.600 So, this is why like tool calling is important on the training side. s37 00:03:51.080 --> 00:04:01.720 Now, let's talk about the product In the previous slide, we showed how the models are trained to emit code in order to solve certain tasks. s38 00:04:01.720 --> 00:04:04.400 The agent executes the code and we verify the reward. s39 00:04:04.400 --> 00:04:08.720 Well, all of this is useless if we don't support this model on the product side. s40 00:04:08.720 --> 00:04:19.239 So, it's basically the same slide as before, but we don't have a training loop and now the hardness is parsing the response and calling the tools and executing the code somewhere, s41 00:04:19.239 --> 00:04:21.239 right? s42 00:04:21.560 --> 00:04:25.560 So, where is this code or tool being executed, right? s43 00:04:25.560 --> 00:04:33.520 This could be your laptop, like with Codex or any agent you want, or it could be a node on the cloud with Codex Web or ChatGPT. s44 00:04:33.520 --> 00:04:44.880 While we can expect the model to generate non-malicious code, but good security practices and hygiene mean that we want to protect our environment, whether it's a laptop or the cloud node. s45 00:04:44.880 --> 00:04:50.800 Attacks can be like intentional or unintentional and we want to protect against those. s46 00:04:50.800 --> 00:04:55.360 And it could be like trying to get root on your system or trying to exploit a kernel variability. s47 00:04:55.360 --> 00:05:02.240 The models are getting really, really big and they might try to help you in an overzealous fashion and try to get root to do so. s48 00:05:02.240 --> 00:05:07.320 So, we want to try and avoid and make sure like it doesn't attack the node or where it's running. s49 00:05:07.320 --> 00:05:10.040 Thus, this is where the sandbox come comes in. s50 00:05:10.040 --> 00:05:19.640 We need the sandbox to run this untrusted code and ensure that it can do its work, but it shouldn't be able to exploit any vulnerabilities and get root on your system. s51 00:05:19.640 --> 00:05:27.160 In the cloud, other sandboxes with other users' data must might be running as well and we don't want it attacking and getting data of other users out. s52 00:05:27.160 --> 00:05:39.480 So, a sandbox is a play an environment in which you can run these tool calls and execute code on behalf of the model securely and it could be on your laptop or it could be on the cloud. s53 00:05:40.480 --> 00:05:46.400 Uh I I think that like everyone's probably used open cloud or any agent like that. s54 00:05:46.400 --> 00:05:51.520 Um I think it's a very very very big peek into what's to come. s55 00:05:51.520 --> 00:05:55.440 A lot of these agents are running locally on your laptops. s56 00:05:55.440 --> 00:06:03.920 And I think it's it's kind of a slap on the face for 20 years of cloud computing that everyone's running this locally on on their laptops. s57 00:06:03.920 --> 00:06:10.640 And if you see the the image, I don't know if this is an actual product, but it's very funny because the lid of the laptop is open. s58 00:06:10.640 --> 00:06:12.960 It's because you don't want your agents to sleep. s59 00:06:12.960 --> 00:06:14.440 Well, we have a whole cloud. s60 00:06:14.440 --> 00:06:16.520 There are like industries built on this thing. s61 00:06:16.520 --> 00:06:21.640 So, I think like the future is like us running your agents in the cloud. s62 00:06:21.640 --> 00:06:23.560 Like they're persistent, long-running. s63 00:06:23.560 --> 00:06:28.320 And I really really hope that moving forward this is not something you see anywhere. s64 00:06:28.320 --> 00:06:30.720 But people rented like VPSs. s65 00:06:30.720 --> 00:06:34.480 They ran open claws on Hetzner or Mac minis in the cloud. s66 00:06:34.480 --> 00:06:44.040 So, I think like open claw was a very very good like peek into like what might be for like sandbox clouds in the future. s67 00:06:44.919 --> 00:06:50.680 We've discussed why sandboxes are important in both research and product. s68 00:06:50.680 --> 00:06:53.200 Uh but they have slightly different needs. s69 00:06:53.200 --> 00:06:57.280 Uh on research, we want to optimize for throughput. s70 00:06:57.280 --> 00:07:02.200 We want to run many many training loops at scale and have many many rollouts. s71 00:07:02.200 --> 00:07:04.600 Um a rollout is one version of a task. s72 00:07:04.600 --> 00:07:05.760 So, what is 3 + 3? s73 00:07:05.760 --> 00:07:08.560 And you might have five or five answers to it. s74 00:07:08.560 --> 00:07:10.600 And one answer is a rollout. s75 00:07:10.600 --> 00:07:14.120 Um we want to take many many shots on goal in parallel. s76 00:07:14.120 --> 00:07:18.320 Um and so, throughput is very very important in research. s77 00:07:18.320 --> 00:07:20.520 In product, latency is very important. s78 00:07:20.520 --> 00:07:25.240 I think any any successful product in the last 20 years has been super fast. s79 00:07:25.240 --> 00:07:32.640 So, if if you don't start a sandbox in time and you don't execute code fast enough, people will churn uh from your product. s80 00:07:32.640 --> 00:07:35.919 Um reliability is important on both both sides. s81 00:07:35.919 --> 00:07:41.240 Like, if you fail constantly, you've wasted like GPU tokens on both sides. s82 00:07:41.240 --> 00:07:43.880 And GPU is like gold right now. s83 00:07:43.880 --> 00:07:48.400 So, we want to just make sure what the tokens you're getting uh are useful. s84 00:07:48.400 --> 00:07:54.800 Uh And similarly on like if if you're not if your agents aren't reliable on the product side, like it's game over, right? s85 00:07:54.800 --> 00:07:56.760 Like people will churn from your product. s86 00:07:56.760 --> 00:08:03.960 Uh security is also important um On the research side, like uh we are training on OpenAI infrastructure. s87 00:08:03.960 --> 00:08:09.240 So, if a model gets root and it's not aligned, it can try to attack OpenAI infrastructure. s88 00:08:09.240 --> 00:08:12.560 It can exfiltrate and release our model weights or whatever. s89 00:08:12.560 --> 00:08:18.160 And then on the product side, it can exfiltrate other users' data, attack the infrastructure as well. s90 00:08:18.160 --> 00:08:24.520 So, security is important for like both both uh research and product. s91 00:08:24.880 --> 00:08:26.960 So, today we'll focus on these three pillars. s92 00:08:26.960 --> 00:08:31.400 There are many many parts of a sandbox cloud, but we'll specifically focus on runtime. s93 00:08:31.400 --> 00:08:35.520 So, how can we run uh sandbox on one node securely? s94 00:08:35.520 --> 00:08:37.880 Secondly, we'll focus on persistence. s95 00:08:37.880 --> 00:08:40.200 Uh I think compute was the first unlock. s96 00:08:40.200 --> 00:08:53.640 People realized you give sandboxes a a Linux computer and they do crazy things because they're pre-trained on so much Linux data, but I think now if you help them if you give them a computer with an actual disk that can be saved, s97 00:08:53.640 --> 00:08:55.760 then they become a true knowledge worker. s98 00:08:55.760 --> 00:09:03.000 And the last part is orchestration and how to run these at scale for many many users at ChatGPT uh and Codex scale. s99 00:09:03.000 --> 00:09:05.000 Yeah. s100 00:09:05.760 --> 00:09:08.280 So, before we start, this is a first principles talk. s101 00:09:08.280 --> 00:09:14.000 So, let's discuss like how Linux executes code on your machine, right? s102 00:09:14.000 --> 00:09:18.080 So, on Linux, a thread is the smallest unit of execution. s103 00:09:18.080 --> 00:09:25.680 Uh the kernel is the thing that provides privileged access to a thread via something called system calls or ioctls. s104 00:09:25.680 --> 00:09:38.200 So, whenever whenever the user space program wants to access some hardware or some privileged resource, it needs to talk to the kernel and call this like operation that switches s105 00:09:38.200 --> 00:09:42.200 the hardware context uh to a more privileged context. s106 00:09:42.200 --> 00:09:45.560 And so, let's look at what that looks like. s107 00:09:45.560 --> 00:09:50.200 So, if you see here, your processor has like different rings of execution. s108 00:09:50.200 --> 00:09:54.200 So, based on which ring you're executing in, you get different privileges. s109 00:09:54.200 --> 00:09:56.640 So, the kernel mode is executing in ring zero. s110 00:09:56.640 --> 00:09:58.240 It has the highest privilege. s111 00:09:58.240 --> 00:10:02.360 And anything in user mode is uh running in ring three. s112 00:10:02.360 --> 00:10:10.000 Whenever we want to access privileged resources, we call system call instructions that change the context of the CPU. s113 00:10:10.000 --> 00:10:14.000 And so, there are two attack vectors in a Linux system, right? s114 00:10:14.000 --> 00:10:15.480 First is getting root. s115 00:10:15.480 --> 00:10:21.000 In getting root, you're still in ring three, but you're the highest privileged user on the system. s116 00:10:21.000 --> 00:10:24.280 So, you can actually pretty much do anything on the system. s117 00:10:24.280 --> 00:10:31.920 You can read your SSH keys, encryption data, etc. And then the second version is actually running a a kernel mode exploit. s118 00:10:31.920 --> 00:10:33.920 So, running code in ring zero. s119 00:10:33.920 --> 00:10:34.680 Uh this is terrible. s120 00:10:34.680 --> 00:10:40.040 You can actually dump processes memories and like like I don't even want to say what all can happen. s121 00:10:40.040 --> 00:10:42.400 So, you can get root and you can have kernel exploits. s122 00:10:42.400 --> 00:10:47.400 And if you get kernel exploit, it's like it's a it's a New York Times article waiting to happen. s123 00:10:47.400 --> 00:10:52.440 So, so these are the two attack vectors on a Linux uh system. s124 00:10:53.000 --> 00:10:58.440 So, with that background, let's design the simplest way to execute tools on a Linux system. s125 00:10:58.440 --> 00:11:03.839 Uh for example, we can literally have an API server that your harness is calling. s126 00:11:03.839 --> 00:11:14.880 And it for every tool call, it can fork a process, exact the tool that the model needs, and just have a fork and exact model, right? s127 00:11:15.000 --> 00:11:18.920 So, now there are a couple of problems uh with this uh model, right? s128 00:11:18.920 --> 00:11:25.160 A, as we discussed the execution model, the fork process can now directly talk to the kernel. s129 00:11:25.160 --> 00:11:32.600 And so, the model can try to attack the kernel, get root, or try to get a kernel exploit, right? s130 00:11:32.600 --> 00:11:39.040 The second thing is imagine you have a while loop and just forking processes in one tool call, right? s131 00:11:39.040 --> 00:11:46.360 So now you've kind of become a bad neighbor or a noisy neighbor and you've kind of brought down the node and no other tool calls can run, right? s132 00:11:46.360 --> 00:11:49.560 So fork exec is the simplest thing you can do. s133 00:11:49.560 --> 00:11:50.880 It has one thing going for it. s134 00:11:50.880 --> 00:11:56.080 It's the most performance solution because there's it's as fast as just forking something. s135 00:11:56.080 --> 00:12:01.520 It's native performance, but everything else is very bad about this solution. s136 00:12:02.720 --> 00:12:06.760 Uh so like we saw that forking and execing was bad. s137 00:12:06.760 --> 00:12:10.200 There was a noisy neighbor issue and there's a security issue. s138 00:12:10.200 --> 00:12:13.640 We now turn to something called containers on Linux. s139 00:12:13.640 --> 00:12:19.240 You must have heard of Docker and other things associated with the containers, but remember this is the first principles talk. s140 00:12:19.240 --> 00:12:24.440 So let's go what deep into what containers are in their very raw form. s141 00:12:24.440 --> 00:12:30.000 Containers rely on two concepts on Linux, namely name spaces and Cgroups. s142 00:12:30.000 --> 00:12:39.680 Uh name spaces are for resource isolation and Cgroups are for controlling the amount of resources a set of processes can consume, right? s143 00:12:39.680 --> 00:12:44.080 So let's see in depth how they can help our problems. s144 00:12:44.080 --> 00:12:51.320 Uh so in this diagram you can see that there are different type of name spaces a set of processes can have. s145 00:12:51.320 --> 00:12:56.040 So on the left you can see this container has a PID name space. s146 00:12:56.040 --> 00:13:08.080 So inside inside that process name space it looks like we have a process hierarchy of PIDs 1, 2, and 3, but if you look at the PIDs from outside the container, s147 00:13:08.080 --> 00:13:10.360 they're just regular processes with other PIDs, right? s148 00:13:10.360 --> 00:13:15.440 So you've abstracted one resource which is the process inside this container. s149 00:13:15.440 --> 00:13:17.560 Another example is a mount name space. s150 00:13:17.560 --> 00:13:28.600 So if you see the bottom half of the diagram, you can mount any file system on top of any mount inside the container, but from outside the original mount is still visible, right? s151 00:13:28.600 --> 00:13:41.120 So, this is a nice way of like isolating different resources in a container, and there are many namespaces like PID, network, mount, etc. Uh So, moving on to the second principle s152 00:13:41.120 --> 00:13:42.160 of containers, right? s153 00:13:42.160 --> 00:13:43.240 Like cgroups. s154 00:13:43.240 --> 00:13:53.760 So, now we have a way to isolate resources within containers via namespaces, but remember I gave the example of uh someone doing a while with fork, right? s155 00:13:53.760 --> 00:13:55.640 Like how can we control that? s156 00:13:55.640 --> 00:14:07.200 Well, we can have cgroups and control how much CPU and memory a container can uh uh consume, and that way like we can like uh make sure that one container doesn't bring down the entire node. s157 00:14:07.200 --> 00:14:18.480 So, namespaces and cgroups provide some amount of isolation uh and uh control on the uh system resources to not bring it down in case it's malicious or bad. s158 00:14:19.360 --> 00:14:29.400 Um if you've seen the previous diagrams, uh there's the the fundamental problem with containers is that they're still native processes uh running on the host. s159 00:14:29.400 --> 00:14:42.200 So, even if we abstract resources and two containers can't attack each other because their resources are isolated, but a process in a container can still exploit the kernel boundary and try to get root or a kernel exploit, right? s160 00:14:42.200 --> 00:14:52.000 And once they can get root, they can attack other people's data from other sandboxes, exfiltrate data, and try to get control of the node like we discussed before. s161 00:14:53.560 --> 00:14:55.680 So, security is a spectrum. s162 00:14:55.680 --> 00:15:00.360 Like you can still get a decent amount of protection from containers. s163 00:15:00.360 --> 00:15:04.120 Uh one example to do this is something called seccomp. s164 00:15:04.120 --> 00:15:13.400 So, you can actually have a filter on the amount of system calls uh your container can call, and you can also control the arguments each system call can take. s165 00:15:13.400 --> 00:15:23.200 So, you can say that you're reducing the attack surface of the kernel uh for for this like container, and like kind of have some amount of sanity on how it can attack the kernel. s166 00:15:23.200 --> 00:15:30.360 The problem with this is that many times you don't know beforehand what system calls some container might call, right? s167 00:15:30.360 --> 00:15:38.240 So, now you're blocking requests for users and later on like you have to like change the set comp filter to allow something or not allow something. s168 00:15:38.240 --> 00:15:44.360 So, the feedback loop is like pretty bad for a product like open claw or any agent that wants to do like crazy things, right? s169 00:15:44.360 --> 00:15:50.600 Like you want to make magical experiences happen in the sandbox and you don't want to restrict them, right? s170 00:15:51.520 --> 00:15:51.920 So, yeah. s171 00:15:51.920 --> 00:16:01.200 The this is the fight like to sum it up like containers interact with the same host kernel, so they do they do have some protections, but at the end it's the same host kernel they're trying to attack, right? s172 00:16:01.200 --> 00:16:12.880 And they can get root and kernel exploits etc. So, we went from like forking to containers like raw fork was obviously very very bad for all the reasons. s173 00:16:12.880 --> 00:16:20.080 Uh containers are better than fork because they still have some protection and you can still have set comp for reducing the attack surface. s174 00:16:20.080 --> 00:16:20.920 Uh can we do better? s175 00:16:20.920 --> 00:16:26.040 Can we reduce the host kernel exposure uh a little bit more? s176 00:16:26.920 --> 00:16:33.839 Yeah, so the second thing we can discuss is uh to solve the attack surface problem is something called Gvisor. s177 00:16:33.839 --> 00:16:37.400 The crux of the security boundary is the kernel API from before. s178 00:16:37.400 --> 00:16:41.360 So, Gvisor uses this point as its key security story. s179 00:16:41.360 --> 00:16:45.160 Uh so, Gvisor implements a lot of sys calls in user space. s180 00:16:45.160 --> 00:16:48.920 You can think of it as an application kernel. s181 00:16:48.920 --> 00:16:56.240 Its sentry is a user space kernel written in Go and the file system is accessed by another daemon called the gopher. s182 00:16:56.240 --> 00:17:03.120 So, the sentry uh implements the Linux API itself including process management, workload management. s183 00:17:03.120 --> 00:17:09.920 And whenever you call a system call, it's intercepted and it's like serviced by this user space uh program. s184 00:17:09.920 --> 00:17:16.280 So, then you can argue that you're not implementing an attacking code that's running in ring zero or kernel mode. s185 00:17:16.280 --> 00:17:21.520 You're actually running in user space and ring three and any exploit you have is still in user space. s186 00:17:21.520 --> 00:17:26.360 So, it's better than you exploiting the kernel directly. s187 00:17:26.920 --> 00:17:35.760 But, the fundamental problem is that the sentry and the gofer, like just going back, the sentry and the gofer are still on top of the host kernel. s188 00:17:35.760 --> 00:17:41.040 So, if there is an exploit on them, you can still have a chained two-step exploit. s189 00:17:41.040 --> 00:17:47.520 So, you first exploit a problem in the sentry or the gofer, and then you exploit from the gofer to the kernel, right? s190 00:17:47.520 --> 00:17:50.360 You can still get to the host kernel eventually. s191 00:17:50.360 --> 00:18:01.040 And with with these models uh of like 5.6 and other types like you can have like like them like figuring out bug reports and these things and like trying to chain exploits, right? s192 00:18:01.040 --> 00:18:05.000 So, you can still get to the host kernel, right? s193 00:18:05.160 --> 00:18:11.280 So, yeah, the chain is harder here because it's a two-step chain compared to the others, but it's still reachable. s194 00:18:11.280 --> 00:18:14.960 Like, can we do better than this? s195 00:18:18.120 --> 00:18:19.120 Yeah, that's the same slide. s196 00:18:19.120 --> 00:18:27.360 It's saying that in all of these uh solutions, you can eventually get to the host kernel, whether it's fork, gVisor, or containers. s197 00:18:27.360 --> 00:18:29.360 Yeah. s198 00:18:29.480 --> 00:18:40.200 So, the key question is can we have a way in which untrusted or malicious code can have exploits, but they can never or find it very very hard to exploit the host, right? s199 00:18:40.200 --> 00:18:47.320 So, even if I can get root, even I if I can exploit the kernel, I still want my host to be protected, right? s200 00:18:47.320 --> 00:18:49.760 Like, that's the final goal we have. s201 00:18:49.760 --> 00:18:52.600 So, do we have something that we can use for this? s202 00:18:52.600 --> 00:18:57.200 So, if you've used if you've like known some of my background, you'll know where I'm going with this. s203 00:18:57.200 --> 00:19:07.000 Uh so, turns out Linux provides a very very nice thing called virtualization, uh which is hardware powered at the CPU level. s204 00:19:07.000 --> 00:19:10.120 And it provides an abstraction at the hardware level. s205 00:19:10.120 --> 00:19:20.080 So, it which means that even if you can get uh root or execute in like ring zero in the guest, your host is still protected. s206 00:19:20.080 --> 00:19:27.920 And this happens because the guest kernel runs in ring zero, but in a separate processor context called VMX non-root. s207 00:19:27.920 --> 00:19:33.400 While the host kernel and the hypervisor run in ring zero in something called VMX root mode. s208 00:19:33.400 --> 00:19:39.120 So, ring zero gives the guest kernel full control inside the guest, but no control on the host. s209 00:19:39.120 --> 00:19:43.880 So, you can exploit the guest all you want, but the host is still protected. s210 00:19:43.880 --> 00:19:51.000 Uh the processor has to switch between the guest and the host whenever the guest wants to access some privileged resource. s211 00:19:51.000 --> 00:19:54.080 We'll see how that works, but that is a key trade-off here. s212 00:19:54.080 --> 00:20:00.080 There's a performance penalty you pay every time the CPU is switching back and forth between these two modes. s213 00:20:00.080 --> 00:20:01.960 Let's see with a diagram what I mean. s214 00:20:01.960 --> 00:20:15.200 Um So, you can see in in the in the old diagram we showed ring zero and ring three for executing users user space and kernel code, but here the guest kernel and the guest user space s215 00:20:15.200 --> 00:20:17.760 uh are running in separate like CPU context. s216 00:20:17.760 --> 00:20:20.000 So, this is guaranteed at a hardware level. s217 00:20:20.000 --> 00:20:29.080 And so, if you can even if you can get to ring zero in the guest, like your host is uh like protected uh from it. s218 00:20:31.280 --> 00:20:32.080 Yeah. s219 00:20:32.080 --> 00:20:37.720 Now, let's talk about what what does paravirtualized and hardware-based virtualization mean? s220 00:20:37.720 --> 00:20:42.640 This is the key of all the VM sandboxes you might have seen on Hacker News or Reddit. s221 00:20:42.640 --> 00:20:44.840 So, we'll we'll go from step by step, right? s222 00:20:44.840 --> 00:20:49.240 So, on the right-hand side, you see something called the VMM. s223 00:20:49.240 --> 00:20:51.400 Can Can every- Can everyone see that on the right-hand side? s224 00:20:51.400 --> 00:20:56.000 It The VMM stands for virtual machine monitor. s225 00:20:56.000 --> 00:21:04.560 Um This software is called a virtual machine monitor, and you might have heard of QEMU when you search search for Linux virtualization. s226 00:21:04.560 --> 00:21:09.120 QEMU and other VMMs, their sole job is to talk to dev KVM. s227 00:21:09.120 --> 00:21:16.040 So, you see that arrow going down like the dev KVM is the hypervisor API of the Linux kernel. s228 00:21:16.040 --> 00:21:28.240 All QEMU and other VMMs do is set up the kernel root FS, set up some allocate some memory for this guest virtual machine, and call like into the dev KVM API. s229 00:21:29.560 --> 00:21:36.360 As discussed inside, when the when the guest runs on the left-hand side, it's running as a completely different Linux system. s230 00:21:36.360 --> 00:21:45.920 It doesn't know what's happening on the host side, but it has these devices like a block device or a net device coming up as regular Linux devices. s231 00:21:45.920 --> 00:21:51.240 But, when it actually tries to access the devices, they exit out to the host context. s232 00:21:51.240 --> 00:21:58.680 And, if you see the block back end and the network back end, they're act There's actually code running emulating the devices in the host. s233 00:21:58.680 --> 00:22:06.080 Uh So, whenever the guest exits out, it's being serviced by the VMM process and these device processes. s234 00:22:06.080 --> 00:22:08.560 So, what do we mean by paravirtualization? s235 00:22:08.560 --> 00:22:16.160 Uh So, paravirtualization means that we want good performance while we want to access hardware in the guest. s236 00:22:16.160 --> 00:22:23.480 So, the guest drivers, when you when the user space talks to them, the guest drivers are aware that they're running in a virtual machine. s237 00:22:23.480 --> 00:22:30.960 And so, they talk via something called virtio, uh which is a more efficient way of the guest and the host talking to each other. s238 00:22:30.960 --> 00:22:34.760 Uh and so, inside they're just PCI devices like any other hardware. s239 00:22:34.760 --> 00:22:39.360 And, when you talk to the PCI devices, you magically exit out onto the host. s240 00:22:39.360 --> 00:22:44.560 Uh so, 15-20 years ago, a bunch of Linux wizards made this thing happen and made this performant. s241 00:22:44.560 --> 00:22:51.680 And, it it it truly is magical like how it works reliably and performantly across different uh hardware processors. s242 00:22:51.680 --> 00:22:57.840 And so, from the host's point of view, when this is running, you just see a block thread. s243 00:22:57.840 --> 00:23:02.840 Like, if you do a PS, you'll see a block thread, but that's running on the guest context. s244 00:23:02.840 --> 00:23:09.720 And when the thread exits out, the thread finally wakes up, it wakes up in this VMM process, and the process runs, and it's running inside. s245 00:23:09.720 --> 00:23:11.720 Yeah. s246 00:23:13.720 --> 00:23:19.800 Yeah, so we had this seismic shift in 2023 where a bunch of new VMMs came. s247 00:23:19.800 --> 00:23:27.360 For a long time, it was just QEMU that was used for running virtual machines, but QEMU has a lot of craft. s248 00:23:27.360 --> 00:23:29.280 It supports many, many architectures. s249 00:23:29.280 --> 00:23:48.680 It has many devices, and it's written in C. And historically, many, many escape attacks were attacking the devices written in C. So, the first the first Rust-based VMM was something called CrosVM, which our team at Google wrote when I was there to support Linux virtual machines on top of Chromebooks. s250 00:23:48.680 --> 00:23:58.200 And the key point here was that we don't need all the craft of QEMU, and we can use Rust to be a memory-safe implementation of this tricky system software. s251 00:23:58.200 --> 00:24:02.600 And secondly, like we have these emulated devices that we can jail. s252 00:24:02.600 --> 00:24:08.520 So, if you attack the block device, we've only given it permission to access block resources. s253 00:24:08.520 --> 00:24:10.280 So, you can't access network resources. s254 00:24:10.280 --> 00:24:16.240 Similarly, if you attack the net device, we we've jailed it, and we don't give it access to block resources. s255 00:24:16.240 --> 00:24:18.880 So, then you can still have a second gate of security. s256 00:24:18.880 --> 00:24:29.160 So, both Rust-based safety, like being memory-safe, and this jailing at a more granular level at the device, like provides better safety than just QEMU. s257 00:24:30.960 --> 00:24:39.480 So, you must have heard this word micro VMs like everywhere, and like no one really answers like why the word micro comes. s258 00:24:39.480 --> 00:24:42.880 So, turns out it has nothing to do with what's running inside the guest. s259 00:24:42.880 --> 00:24:45.920 It's It's everything to do with the VMM itself. s260 00:24:45.920 --> 00:24:58.400 So, all these new-age Rust-based VMMs, they have a much smaller memory footprint because they don't support as many devices, and they also boot much faster because they don't have as much craft. s261 00:24:58.400 --> 00:25:07.840 So, a mixture of like just less blue less bloat and just booting a faster is why the industry has called them micro VMs. s262 00:25:08.720 --> 00:25:11.120 Uh one second. s263 00:25:11.120 --> 00:25:12.640 Yeah, sorry. s264 00:25:12.640 --> 00:25:15.680 And then you must have seen Firecracker and Cloud Hypervisor. s265 00:25:15.680 --> 00:25:18.640 I There's a lot of confusion around what who came before. s266 00:25:18.640 --> 00:25:28.360 Cross VM was the first like Rust based VMM that came before and then Firecracker forked Cross VM and it's used on Amazon for their Lambda and serverless load. s267 00:25:28.360 --> 00:25:41.920 And Cloud Hypervisor is a more general like VMM that many many companies like contribute to and when you historically see micro VMs on the internet like it's powered by one of these VMMs basically. s268 00:25:43.320 --> 00:25:47.400 So, it may seem complicated but at the end everything is APIs. s269 00:25:47.400 --> 00:25:49.560 Micro VMs are no different. s270 00:25:49.560 --> 00:25:53.280 So, here's a small view of how you can actually start a micro VM. s271 00:25:53.280 --> 00:25:58.200 So, your harness actually forks a Cloud Hypervisor binary process. s272 00:25:58.200 --> 00:26:02.960 When the process starts, it exposes an API over a Unix domain socket. s273 00:26:02.960 --> 00:26:09.800 And if you can see in step two, we call the create API, give it like the root FS, kernel, CPU, and memory. s274 00:26:09.800 --> 00:26:11.280 And then we finally call start. s275 00:26:11.280 --> 00:26:23.440 And when we call start, you can see from previous diagrams that the VMM literally calls into dev KVM just like before and it starts these like guest micro VM. s276 00:26:24.680 --> 00:26:32.640 And then once the guest is running the like in this case the agent sandbox is running, it might be that I want to talk to something inside the sandbox s277 00:26:32.640 --> 00:26:37.960 to say that hey, save your state or I'm attaching some devices or I'm doing some XYZ operation. s278 00:26:37.960 --> 00:26:50.440 So, generally in in agent sandboxes, you have a PID one that exposes an API server and your harness or something on the outside is talking to this API server. s279 00:26:50.440 --> 00:27:02.720 And then this is the way how you can use like micro VMs to be agent sandboxes that that can run like more securely than the other primitives that we showed. s280 00:27:03.520 --> 00:27:09.600 Uh, in this case we are using Vsock, which is a socket that can help you communicate between the guest and the host. s281 00:27:09.600 --> 00:27:13.640 Or you can use the IP stack on the node itself. s282 00:27:14.600 --> 00:27:17.520 And so there are no free lunches in systems. s283 00:27:17.520 --> 00:27:18.920 And so there are some trade-offs. s284 00:27:18.920 --> 00:27:25.240 So obviously you get really really good isolation using micro VMs at a hardware level. s285 00:27:25.240 --> 00:27:27.520 You can still attack the host, but it's much harder. s286 00:27:27.520 --> 00:27:31.720 You have to attack the KVM stack and then you have to attack the device. s287 00:27:31.720 --> 00:27:37.840 The chain is much much harder to do, but it has been seen and I'm sure it will be seen more with these models. s288 00:27:37.840 --> 00:27:40.520 Um, you can jail the devices generally. s289 00:27:40.520 --> 00:27:44.880 So you can use seccomp and other security hardening things for the devices. s290 00:27:44.880 --> 00:27:50.160 So even if you get compromised on one device, your whole system cannot be brought down. s291 00:27:50.160 --> 00:27:53.080 Um, and like I said, there is a performance overhead. s292 00:27:53.080 --> 00:28:03.960 Like like when you were exiting and and entering the host and the guest context, it's a very very heavy operation and you pay in like performance. s293 00:28:03.960 --> 00:28:05.960 Memory sharing is not as easy. s294 00:28:05.960 --> 00:28:12.120 There's something called a balloon driver and so you have to actually ask the guest to give back memory and reclaim it. s295 00:28:12.120 --> 00:28:14.520 So it's always a like reactive thing. s296 00:28:14.520 --> 00:28:17.680 You can't immediately like reclaim and claim memory. s297 00:28:17.680 --> 00:28:26.880 Um, and then a lot of sandboxes these days have GPU access, presumably for auto research or some sort of like ML research type of agents. s298 00:28:26.880 --> 00:28:29.240 This is not as easy with micro VMs. s299 00:28:29.240 --> 00:28:36.480 There's something called vert IO GPU, but that provides high-level graphic library type access. s300 00:28:36.480 --> 00:28:42.720 For metal access, direct metal access there's something called VFIO, but it can only be shared by one sandbox at a time. s301 00:28:42.720 --> 00:28:44.840 It cannot have multi-tenant things. s302 00:28:44.840 --> 00:28:54.480 But given all of this, my view is that security like system tricks can cover performance issues, but they cannot hide security breaches. s303 00:28:54.480 --> 00:28:58.520 And as a company, you can lose trust once and it's like very hard to regain. s304 00:28:58.520 --> 00:29:06.240 So, I always prefer the more secure solution and try to make make make make up with system tricks for performance issues. s305 00:29:06.240 --> 00:29:14.160 And in my history of like working on sandboxes, I've seen there are like I would call it like the seven stages of grief, the seven stages of sandboxing. s306 00:29:14.160 --> 00:29:18.880 Like in the end, everyone always wants a VM because they tried everything. s307 00:29:18.880 --> 00:29:21.520 They tried containers, G visor, V8s. s308 00:29:21.520 --> 00:29:28.080 And then they realize, "Oh, I want a whole Linux box because I don't want to like end up without XYZ functionality." s309 00:29:28.080 --> 00:29:31.800 And if I want a whole Linux box, I want to obviously be secure. s310 00:29:31.800 --> 00:29:38.240 So, if you're a startup or a founder like in this space, like let me save you the story and two years of grief. s311 00:29:38.240 --> 00:29:40.880 Just please use micro VMs from the start. s312 00:29:40.880 --> 00:29:44.520 And then if it doesn't work, tell me and then we can talk about other things. s313 00:29:44.520 --> 00:29:49.040 So, now we've discussed how to run untrusted code on one node. s314 00:29:49.040 --> 00:29:56.480 And I think now like people have woken up to the fact that these models are very very good drivers of Linux boxes. s315 00:29:56.480 --> 00:30:01.880 Like so, if you give them a computer, they can just pretty much do magical things as we've seen with open claw. s316 00:30:01.880 --> 00:30:04.640 They just pre-trained on a lot of Linux, right? s317 00:30:04.640 --> 00:30:08.600 However, like imagine if I gave you a computer without a disk. s318 00:30:08.600 --> 00:30:12.960 Every time you close the laptop, like your data and your work goes away, right? s319 00:30:12.960 --> 00:30:15.160 Like that's not a fun world to live in. s320 00:30:15.160 --> 00:30:20.760 And And somehow the agents are some in the cloud at least are in this sort of world right now, right? s321 00:30:20.760 --> 00:30:23.440 So, we want to give them durable storage. s322 00:30:23.440 --> 00:30:30.320 And so, this this part of the presentation is specifically working on disk storage, not memory persistence, but disk persistence. s323 00:30:30.320 --> 00:30:35.400 So, let's see why it's important and how we can do it. s324 00:30:36.680 --> 00:30:40.720 So, as shown in previous diagrams, your micro VMs have disks attached to them. s325 00:30:40.720 --> 00:30:46.160 Uh they might be just files or other disk devices on the node that you pass through to the VM. s326 00:30:46.160 --> 00:30:56.600 Um And so, from a product perspective, the task the task that the users are doing in these sandboxes are becoming much more complicated and much more longer horizon. s327 00:30:56.600 --> 00:31:02.320 So, people are making like presentations and entire GitHub repos are being created inside the sandbox. s328 00:31:02.320 --> 00:31:11.360 Now, now imagine if like the node dies on the cloud or the model has a flake, and you created this like presentation and like you just lost it, right? s329 00:31:11.360 --> 00:31:15.680 It's It's A bad for us because we wasted a bunch of GPU tokens. s330 00:31:15.680 --> 00:31:20.760 It's obviously bad for the user because you did a lot of this work and and you lost it. s331 00:31:20.760 --> 00:31:33.000 So, not just from a product perspective, but just from like a good experience and like utilization perspective, we need to have some way to save the disk state of the sandbox. s332 00:31:33.000 --> 00:31:39.440 And let's go into like three big use cases on what persistence can unlock, right? s333 00:31:40.040 --> 00:31:45.240 So, counterintuitively, persistence actually helps reliability and scale. s334 00:31:45.240 --> 00:31:49.240 They might seem like orthogonal concepts, but but they're very much related. s335 00:31:49.240 --> 00:31:58.600 So, for instance, you have a long-running task in a sandbox that has many packages installed and and you've created like GitHub repos and presentations and things, right? s336 00:31:58.600 --> 00:32:08.120 If you keep checkpointing it periodically and if the node fails or the cluster fails, you can now restore the sandbox in the exact checkpoint state on another node. s337 00:32:08.120 --> 00:32:13.440 You can also do it intentionally if you want to upgrade a cluster or do some AB testing on nodes. s338 00:32:13.440 --> 00:32:17.720 The persistence has now let you reliably run sandboxes across your fleet, right? s339 00:32:17.720 --> 00:32:21.520 So, it's a very good way to scale and be reliable. s340 00:32:23.760 --> 00:32:29.000 Like I said, like how many of you have used gold mode in Codex or know what it is? s341 00:32:29.000 --> 00:32:30.360 Yeah, amazing, right? s342 00:32:30.360 --> 00:32:44.520 So, if you if you run gold mode, now it's like like my I think 3 days is my record for running something, but like now people are doing longer and longer tasks and I think this trend will continue in the cloud as well. s343 00:32:44.520 --> 00:32:53.520 So, to support this we obviously like need to have checkpointing so that the model can save state, restore it on another node and like you can keep going forward and forward, right? s344 00:32:53.520 --> 00:32:59.600 Like and so you're resilient to any failures across in the in the infrastructure. s345 00:33:00.240 --> 00:33:02.320 This is the most interesting part actually, right? s346 00:33:02.320 --> 00:33:14.600 Like so, if your harness wants to explore multiple like solutions or sample spaces, it can actually checkpoint the sandbox state and it can like do a Monte Carlo like tree search s347 00:33:14.600 --> 00:33:17.360 and like go ahead and like backtrack, checkpoint again. s348 00:33:17.360 --> 00:33:24.040 So, this way it can actually do rollouts over many, many days and come back with the actual like solution, right? s349 00:33:24.040 --> 00:33:35.040 And I think my sincere hope is that if if we make this infrastructure correct, we can help like solve diseases, like find new drugs because the model can just keep going on for longer and longer, right? s350 00:33:35.040 --> 00:33:40.760 But it doesn't happen till we have really, really rock solid primitives to do this. s351 00:33:41.240 --> 00:33:51.840 And so, given the needs and the the the pillars we want to support, here are some of the things that this snapshotting solution should support, right? s352 00:33:51.840 --> 00:34:03.040 First at ChatGPT or Codex scale, we want to do incremental snapshotting and what that means is like if you call snapshot twice, I'm just snapshotting the diff between the two snapshots. s353 00:34:03.040 --> 00:34:13.120 Otherwise, if I have to save gigabytes of data at every turn, like like I'm going to bankrupt the company and like it's just a slow experience regardless, right? s354 00:34:13.120 --> 00:34:22.360 The snapshotting API itself should be very, very cheap and fast so the model and the harness can keep snapshotting and exploring like very fast. s355 00:34:22.360 --> 00:34:36.480 And similarly, like just like creation should be fast for products, like restoring is just nothing but just creation from a snapshot and so restoring should also be very very fast for a good product experience. s356 00:34:36.480 --> 00:34:38.560 And then we have two paradigms we'll discuss. s357 00:34:38.560 --> 00:34:50.280 One is always saving in which the harness doesn't have to explicitly call a save API versus explicit explicit saving where the harness is calling save save save. s358 00:34:50.280 --> 00:34:55.480 We'll see how we can implement both so I'll give a reference solution. s359 00:34:57.760 --> 00:35:01.320 And then there are some more design choices with disk snapshotting, right? s360 00:35:01.320 --> 00:35:06.000 So first like I said on the left hand side, do you want incremental or full snapshots? s361 00:35:06.000 --> 00:35:09.880 I argue I think at our scale we want incremental snapshotting. s362 00:35:09.880 --> 00:35:22.040 Secondly, like do you want to snapshot the entire root FS or do you want to have certain folders like workspace or mount something something that you want to you want to keep that like configurable. s363 00:35:22.040 --> 00:35:27.800 And lastly like you we can see how you can snapshot at a file system level or at a block. s364 00:35:27.800 --> 00:35:32.800 So I in Linux disks are nothing but block devices and each file maps to different blocks. s365 00:35:32.800 --> 00:35:34.200 We'll see after this. s366 00:35:34.200 --> 00:35:43.200 And so you can do very very efficient like snapshotting by just zipping up the blocks that have changed for a file or you can do entire files that have changed, right? s367 00:35:43.200 --> 00:35:45.280 For more right amplification. s368 00:35:45.280 --> 00:35:58.360 And the high level flow of snapshotting is basically you figure out what's changed, you zip it up, put it in the cloud and then when you restore you pull it down and and you restore the micro VM, right? s369 00:35:59.720 --> 00:36:06.720 And so this is a first principles talk and so I just wanted to go over how Linux storage works from first principles. s370 00:36:06.720 --> 00:36:09.800 So Linux represents disks as block devices. s371 00:36:09.800 --> 00:36:15.960 So you see on the right like it thinks of a block device as having logical blocks from zero to end. s372 00:36:15.960 --> 00:36:28.920 A file system maps directories and files into something called an inode data structure and the inode says okay, offset zero in file F maps to this block logical block in disk D s373 00:36:28.920 --> 00:36:37.120 and then on the disk itself there's firmware running which says oh logical block one is like sector 100 or sector 500 or page XYZ. s374 00:36:37.120 --> 00:36:45.200 So the hierarchy is on these logical blocks up to the file system and we leverage that for block based snapshotting. s375 00:36:45.600 --> 00:36:49.560 And then within a micro VM there are two ways of accessing storage. s376 00:36:49.560 --> 00:36:58.600 On the left hand side you can think of this as sharing a folder like Google Drive but it's very very inefficient cuz you're the VM is doing file system s377 00:36:58.600 --> 00:37:03.840 operations exiting at every file system operation which is very inefficient. s378 00:37:03.840 --> 00:37:14.680 On the right hand side you actually give a disk like abstraction at a block so you give a block device to the micro VM and it is way more efficient because you can use the caches inside s379 00:37:14.680 --> 00:37:17.760 the guest and you don't have to exit out as much. s380 00:37:17.760 --> 00:37:23.920 You only exit out when you truly need to access the block device and the host has to service you. s381 00:37:25.760 --> 00:37:33.240 This is the high level diagram of how you will have always on persistence in disk snapshotting. s382 00:37:33.240 --> 00:37:45.240 So if you have two micro VMs they have a block device which they will see this dot image as a block device inside and as they are writing to the block device we are writing through to the cloud. s383 00:37:45.240 --> 00:37:52.720 So there's some sort of like distributed file system that we mount inside that's giving this always on persistence. s384 00:37:53.000 --> 00:38:01.600 And like I mentioned for explicit persistence we have an actual API called the save API. s385 00:38:01.600 --> 00:38:09.600 Calling the save API from the harness figures out what figures out what's changed between the last snapshot. s386 00:38:09.600 --> 00:38:14.480 It bundles up this div into an artifact and returns a snapshot ID. s387 00:38:14.480 --> 00:38:27.120 Later on you can give us this snapshot ID we figure out the lineage of snapshots that make this snapshot ID and then we download them one by one and apply it on the node, and you get a micro VM restored with this thing. s388 00:38:27.120 --> 00:38:31.680 Uh so, let's see like how how we can implement this, right? s389 00:38:32.640 --> 00:38:33.280 Give me 1 second. s390 00:38:33.280 --> 00:38:36.320 I want to see how we are doing on time. s391 00:38:41.040 --> 00:38:43.760 I think we have 5 minutes left, so we can go fast. s392 00:38:43.760 --> 00:38:49.360 Yeah, so uh we can do explicit persistence uh using something called copy-on-write. s393 00:38:49.360 --> 00:38:54.080 So, Linux has these XFS file systems uh XFS-like file system. s394 00:38:54.080 --> 00:39:04.040 So, you can do pretty pretty much have zero latency copies because you don't change any blocks when you copy, but when you actually change the blocks on a file, s395 00:39:04.040 --> 00:39:05.640 that's when you pay the penalty. s396 00:39:05.640 --> 00:39:14.160 And so, in this in this design, we have a base.image, which might be the Code X base image or whatever like the chat GPT base image. s397 00:39:14.160 --> 00:39:17.640 We create a zero copy on top of it, which is a writable layer. s398 00:39:17.640 --> 00:39:21.400 And then when you write to it, now you're changing the blocks in this layer. s399 00:39:21.400 --> 00:39:28.520 And then when you want to snapshot, I use something called FIE map, which tells me what blocks have changed and what ranges. s400 00:39:28.520 --> 00:39:32.280 I zip that up and store it to the cloud. s401 00:39:32.280 --> 00:39:34.720 And I can do something very nifty here. s402 00:39:34.720 --> 00:39:37.600 I can actually lie to you while I'm uploading to the cloud. s403 00:39:37.600 --> 00:39:42.320 So, the snapshot can happen return very fast as I'm uploading in the background. s404 00:39:42.320 --> 00:39:45.920 I don't have to wait till I'm back till I'm uploading. s405 00:39:45.920 --> 00:39:57.600 And then on the other side like I have this diff, I download this like artifact, I figure out what extents have changed, then I apply it back on top of the base image, and I start the micro VM again. s406 00:39:57.600 --> 00:40:03.560 So, now we have a restored sandbox with the exact same state at a block level, right? s407 00:40:03.560 --> 00:40:05.920 Now, how can we do always-on persistence, right? s408 00:40:05.920 --> 00:40:08.560 Like uh So, this is one way of doing this. s409 00:40:08.560 --> 00:40:16.560 I know there's NFS also and other like distributed file systems, but NFS, for instance, isn't as performant and is not POSIX-compliant. s410 00:40:16.560 --> 00:40:21.040 And I think our models are just very good at anything POSIX compliant and standard. s411 00:40:21.040 --> 00:40:29.080 So, you can write a you can write a file system actually on top of a GCS or S3 or durable block storage. s412 00:40:29.080 --> 00:40:30.720 And you can use something called NBD. s413 00:40:30.720 --> 00:40:34.280 So, within the sandbox, you'll actually see a block device. s414 00:40:34.280 --> 00:40:44.560 But inside, it will have literally a tiered cache of blocks that are persisted first to an in-cluster cache, and then the in-cluster cache is like writing back to the s415 00:40:44.560 --> 00:40:46.720 block storage the object storage. s416 00:40:46.720 --> 00:40:58.800 So, you have this like nice global tiered architecture where you're actually like caching things at the block level and finally inside the micro-VM and get a very performant like file system inside. s417 00:40:59.560 --> 00:41:03.960 Yeah, so that's the persistence part of the presentation. s418 00:41:03.960 --> 00:41:08.640 And so, the one takeaway I want you guys to think about is I think storage is the next unlock here. s419 00:41:08.640 --> 00:41:19.080 As you're working on sandboxes, think of what what all you can snapshot and restore fast to give like this new paradigm to harnesses so they can recover from failures and explore s420 00:41:19.080 --> 00:41:21.080 do Monte Carlo like searches. s421 00:41:21.080 --> 00:41:23.760 So, we've discussed running things on one node. s422 00:41:23.760 --> 00:41:26.360 And of course, if our one node dies, we are done. s423 00:41:26.360 --> 00:41:29.920 So, we want to be able to run across many many nodes across the world. s424 00:41:29.920 --> 00:41:33.440 So, I'm not going to mention about Kubernetes or other like acquisition things. s425 00:41:33.440 --> 00:41:34.760 This is a first principles talk. s426 00:41:34.760 --> 00:41:39.320 So, we'll lightly hint about the challenges here. s427 00:41:39.360 --> 00:41:44.440 So, ideally, we want multiple machines to support the runtime we discussed. s428 00:41:44.440 --> 00:41:49.280 So, we can group nodes into clusters and spread the clusters across the regions. s429 00:41:49.280 --> 00:41:53.720 Our top-level control plane chooses a cluster using region load and other factors. s430 00:41:53.720 --> 00:41:57.760 And it's not very different from the orchestrators you're familiar with. s431 00:41:57.760 --> 00:42:06.440 Um these like it ideally chooses a cluster close to your chat GPT cluster so you can like have fast like access to the harness. s432 00:42:06.440 --> 00:42:08.520 Inside the cluster, there's a scheduler also. s433 00:42:08.520 --> 00:42:12.840 And the scheduler tells you which node to pick based on the load and other factors, right? s434 00:42:12.840 --> 00:42:15.760 So, if nodes are dying or failing, it won't choose that. s435 00:42:15.760 --> 00:42:18.840 It will intelligently like route the sandbox to the thing. s436 00:42:18.840 --> 00:42:25.240 And again, low latency and reliability remain very, very key North Stars for this architecture. s437 00:42:26.320 --> 00:42:31.200 And so, here like we can use some micro VM features to support low latency creation ideas. s438 00:42:31.200 --> 00:42:33.760 So, a lot of systems cheat for low latency. s439 00:42:33.760 --> 00:42:38.520 They pre They pre-warm like sandboxes and they pick one, which is great. s440 00:42:38.520 --> 00:42:47.120 Another way to do this is you can actually take a memory snapshot of a micro VM and just-in-time start it start it in milliseconds as the request comes. s441 00:42:47.120 --> 00:42:53.400 And so, you can leverage this like nice micro VM property that you can save the guest memory and start from that. s442 00:42:53.400 --> 00:42:55.080 And the third one is a hybrid solution. s443 00:42:55.080 --> 00:43:00.680 So, you can have a warm pool, but as it's growing, you can like grow it from the memory snapshot. s444 00:43:00.680 --> 00:43:02.520 So, you can get best of both worlds. s445 00:43:02.520 --> 00:43:09.000 Like, the trade-off for a warm pool is that you're you're consuming CPU and memory uh in idle state. s446 00:43:09.000 --> 00:43:10.640 Ideally, you don't want to do that, right? s447 00:43:10.640 --> 00:43:15.560 So, there's a trade-off between uh one and three and two, basically. s448 00:43:15.560 --> 00:43:21.400 And so, here is a way where we can use snapshot rich restore for better orchestration. s449 00:43:21.400 --> 00:43:25.880 So, remember we discussed that a snapshot can have a lineage of many, many layers. s450 00:43:25.880 --> 00:43:33.680 So, once you want to restore from a snapshot and you find out you have like, let's say, four layers that you want to pull down and that makes the lineage. s451 00:43:33.680 --> 00:43:39.080 You can actually like smartly route you to a node which has to download the least amount of stuff. s452 00:43:39.080 --> 00:43:46.160 So, in this diagram, you can see node A has some layers, node C has some layers, but node B has all the layers that you need. s453 00:43:46.160 --> 00:43:52.120 So, the scheduler then routes you and it it gives it the highest score and routes it because it has all the snapshot layers. s454 00:43:52.120 --> 00:44:03.040 So, you can use like snapshot with orchestration to just have faster like uh uh creates and even just more reliable uh uh like orchestration. s455 00:44:03.040 --> 00:44:14.520 Yeah, this is the talk and I hopefully it gives you some design intuition around like sandboxes, why they're important, what's the next unlock, and I want to see more of you guys using it in a secure way. s456 00:44:14.520 --> 00:44:16.720 Thank you.