 All right when the program committee saw this talk we were curious and we hope that you are too This is Kohei who's joining us all the way from Japan from NTT. Please join me in welcoming him to the stage Okay, good morning everyone. Hi, I'm Kohei Tokunaga from NTT corporation I'm mainly working on things related to container runtimes and builders and I'm a maintenance build kit and a review of cncf container d Today I'm going to talk about container to wasm converter This is an approach to run existing existing Linux based applications on wasm and browser Without modifications to apps So first of all, this is the summary of this talk Putting the apps to wasm it costs time for recompilation and our re-implementation And container to wasm enables running unmodified containers on wasm levelizing cpu emulators And we've created an extension of vscode for the web to run containers on browser So First of all, why porting apps to wasm? Well, we can find lots of use cases of porting applications to wasm in community One of the benefits of porting apps to wasm is Levelaging existing apps on browser They can be used used as their environment as building blogs and for demo pages, etc And languages including ruby and python and databases like sql 3 and postgres are ported to Wasm and can be used on browser And second benefit is that applications can levelize wasm features For example, apps can be sandboxed by wasm and it's highly portable and can run on anywhere The runtime is available including browser And their wasm related technologies are like that are useful Including pre initialization of applications by weather and record and replay by timecraft But porting apps to wasm is not easy actually This requires developers to at least recompile the application And it might require re-implementing the part of application if it can't run on wasm And there are some factors that causes this incompatibility First one is the difference of binary format So non-wasm binaries like x8664 don't run on wasm So recompilation will be needed for porting apps And the app might need to be redesigned for wasm architecture And this might include eliminating like a fork and egizek related calls, etc And kernel aprs are also different If application relies on Linux specific feature, it needs to be re-implemented Not to rely on that So some of the issues can be mitigated by compiler's wasm target support But they still don't provide fully compatible APIs to the existing system So can we port unmodified applications to wasm? So here container to wasm converter comes in A container to wasm is an experimental converter of container to wasm It receives an arbitrarily Linux-based container as the input And it outputs an wasm image that runs the container on wasm The Linux-based containers and applications in it run on wasm without modifications And this is achieved by CPU emulators ported to wasm And using this converter, containers can run on washy runtimes and on browser as shown in the pictures in this slide So container to wasm converter outputs an wasm image that supports washy by default Basic features are supported including stdio environment variables and sharing directly from the host to the container And networking is also usable as of now networking stack needs to run outside of the runtime So I'll talk about it this feature later And the following command line shows an example of running Ubuntu 22.04 container on wasm So uname command tells it is a Linux x8660 for environment And containers root file system is available on wasm as is And directly on the host cannot also be mapped into the container And containers are converted to wasm So of course it can run on browser as well There are two types of configurations available First you can run the container converted to wasm image on-browser Actually, there are some existing on-browser wasm host Implementation available in community so you can use the favorite one And another configuration is based on emscripten Containers to wasm can emit emscripten wasm image plus js files that run on-browser And please note that some features that rely on washy like why the pre-initialization are unavailable for emscripten image as of now And networking can also be enabled for containers on-browser I'll describe it later And the picture in this slide is an example of running Ubuntu 22.04 on-browser And containers converted to wasm image can perform networking As of now it relies on networking stack running outside of the wasm runtime This is provided as c2w net command The example in this slide shows running alpine linux on wasm And this downloads figlet command from the internet using apk command and runs it As of now this works on wasm time and wasm row And containers converted to wasm can perform networking on-browser There are two types of configurations The first configuration relies on networking stack helper running outside of browser That networking stack forwards the containers packets on the machine Pros of this approach is that the container can access to Anywhere accessible from that host side networking stack without reselection by browser And cons is this requires of course running and managing extra networking stack demon outside of the browser And another configuration allows the container on-browser performing networking without extra networking stack demon outside of browser So the networking feature is implemented purely on-browser A pro of this mode is that this is a needed-to-use approach because extra demon is not needed But cons is that it only supports HTTP and HTTPS as of now and Browsers security restrictions are applied to the container as well Let's say container cannot access to cross-origin restricted sites and some HTTP headers Called forbidden headers aren't controllable from the container So actually you can try the demo of the containers on-browser On the demo page hosted on github pages as shown here and Yeah on that page actually we have Several demos for x86 64 containers and risk 5 containers And we have three images here But uh, yeah, let's try debian image today And then you can see the black screen in this page Now this page Yeah, not okay Now yeah this page Loads the wasm image converted from the debian container image described at the top of this page and Then the wasm image is fully loaded to the browser and it starts a shell of debian container and By executing a uname command you can confirm that this is the linux x86 64 environment And according to slash atc slash os release. This is a debian container And you can see the root file system at slash and Actually this page also enables the on-browser networking stack so This is the c url command Pointing to this github page itself Actually the networking is not so fast as of now. So you need to wait for a while to complete the command Then you'll see the fetched html contents on the shell So how container to wasm works? First of all the conversion steps from the input container to output wasm is written in docker file and runs on docker build as a build kit And we use cpu emulators compiled to compiled to the wasm for running native binaries on browser For x86 64 containers box emulator is used and for risk 5 containers a tiny emulator is used Emulator and dependencies are packaged into a single wasm image for wasi image Wasi vfs provides packaging ability For image scripting image we use dash dash preload dash file feature of packaging And and for minimizing the startup time we experimentally use wiser pre-initializer and this pre-boot the kernel during the conversion step So at runtime the container immediately starts on the pre-booted kernel and emulator sees mapped directly via wasi apis fd apis And these pre-opened directly are shared between The emulator and the guest os via vertio 9p And for networking on wasi image rushy runtimes The emulator provides vertio net device to the guest Linux And as shown in the picture the emulator for packets relying on the network stack c2w net running outside of the wasi runtime The emulator and c2w net are connected over wasi's SOC apis And c2w net is implemented based on divisor slash vsoc which is a networking stack written in go And we added some features for our use case like wasi runtime support And for on-browser configuration as shown in the picture again, we use c2w net for other running outside of the browser The emulator on-browser and c2w net on the host are connected over web socket and exchange packets And another approach is running networking stack on the browser So host side networking stack demon is not needed This networking stack supports forwarding HTTP and HTTPS connection to the outside of the browser using fetch API And HTTPS connection is terminated at the networking stack on the browser With its own certificates and the connection is re-encrypted by fetch API And actually this is needed to use configuration because the entire networking stack runs on browser However, there are some resolutions by fetch API Let's say accessible sites are limited by cores and forbidden headers can't be controlled by container etc And of course we expect applying the ability of running containers on wasm to various kinds of use cases But one of the interesting ones should be running containers on browser-based IDEs So vscode container wasm is an experimental extension of vscode for the web This enables to run containers on browser and provides terminal to the vscode on the browser The container runs on browser, so you don't need to prepare remote containers And the workspace directly is mounted at slash workspace and networking is also available based on fetch API With restrictions by browser like codes And this is implemented using Microsoft slash vscode dash wasm for washi host for containers as of now And again you can try this extension on your browser Here we use github.dev here And this is a vscode ID integrated to github And here you can run the container on browser using an extension named container wasm This is available on the marketplace And this repo has dot vscode slash settings.json This is a config file points to the url of the devian container converted to wasm And yeah, we want to use that wasm image converted from devian on this workspace So let's launch this container. So when you invoke the commander Run container on browser This extension reads the settings.json value of the workspace and launches the pointed container on your browser And yeah after wasm image is fully loaded to the browser it starts the shell of the devian container And by executing a username command again So you can confirm that this is the linux x86 64 environment And you can also see the workspace directly is mounted at slash workspace And for this demo this converter This container contains gcc. So let's compile the ccode sorting this repo The ccode is pretty simple. It just brings hello world as shown in the IDE and yeah, finally when we execute it out, it brings hello world as expected Okay, and uh, yeah not limited to not limited to on-browser ids We believe there are some expected use cases or possible use cases of running containers on wasm For example interactive on-browser linux based demo environment on-browser ids sandbox execution environment for containers And application debugger runable on-browser and record and replay debugging etc And yeah, actually this project is still in a very very un-arri-stage So we expect further improvement, of course first Big one is performance analysis and improvement And also accessing to os package repos From browser is also What we currently lack So most repos doesn't allow cross origin access as of now. So these repos need to allow cross origin access And as a usability improvement And graphic support to set over also we expect And there are some existing approaches for running a modified applications on wasm. I listed some of them here v86 is x86 x86 compatible cpu emulator running on browser by fabio hema and I Supports wide variety of guest oasis and actually it doesn't support x86 64 as of now and not target to wasi And tiny emu is a risk 5 and x86 emulator created by created by fabry's build And it can run on browser and actually container to wasm uses this for risk 5 emulation Actually, it doesn't currently support x86 64 cpu emulation and not not target to wasi and Final one is not on vm on browser, but it is binary translation myaot The name will is subject to change But myaot is a translator of a Linux risk 5 elf binary to wasm proposed by akihiro soda entity Actually, it is no and it is not cpu emulator and Currently it is under the experimental status. So only trivial programs work and the syscalls are not fully implemented yet So finally, this is the summary of this talk porting ups to wasm cost time for a recompilation and or re-implementation And container to wasm enables running a modified containers on wasm devalaging cpu emulators And we've created an extension of vs code for the web to run containers on browser Future works will include performance analysis and improvement cross-origin enabled or its package repository to situa Get that all thanks All right. Thank you so A totally different approach than what we saw in the in the earlier talk enabling lifting and shifting into wasm Does anyone have any questions? Come in the back. Yeah, thank you for your talk One of the issues that i'm running into with a bunch of my customers is that they actually have a lot of old 32 bit windows pc's that they Don't have any ability to lift and shift I was wondering, uh, have you looked at actually maybe using Windows as the what's being emulated and maybe being able to take like a I'm going to go back what 10 15 years here, but p2v and then actually take that vm and put it onto wasm Thank you for the question. The question was about The plan the support for windows, especially all the windows actually Yeah, we haven't we have not looked to the windows support yet but like yeah, actually The emulation of windows on brother is kind of Yeah, I'm already approached to work by v86 So maybe we can we haven't looked at it deeply but Yeah, maybe in the future we can support non linux applications as well on brother, but uh, yeah Yeah, but we don't have any concrete planets. So yeah, actually Proposals and suggestions suggestions Always welcome. Hey cohey Question from over here. Uh, thank you for the presentation. It was awesome. I'm into this like inception stuff I would love to see wasm time inside a vm Inside wasm time Let me know Um, my question is when I assume you've done some benchmarking Uh, what's the performance overhead of this emulation? Is it 10x 100x? Uh, thank you for the question. The question was about benchmarking and performance of this approach. Yeah, um As mentioned in this slide Yeah We we we have not worked on benchmarking yet. So this is uh, actually kind of top priority of For for this approach. Uh, so yeah, um, the main overhead I Expect is of course cpu emulation. Uh, there is no jit Is done as of now. So yeah, but uh, yeah Of course, uh, we want to uh, analyze this deep deeper. Yeah. Thank you for the question. It is definitely good question Andrew brown was in and and comedy Only in wasm cup or wasm day too many wasm Pretty much the same question just on size Uh, you know, we were talking about performance, but just size wise the binary in the end. What's the difference maybe the binary size Okay, thank you for the question Yeah, the question was about again our performance and especially about binary size. Yeah, as of now the binary size is big actually, uh For example, yeah in terms of uh um Yeah x86 64 containers a debia image is currently 200 megabyte But the original debian image is like around At most 50 megabyte or yeah, but uh, it is quite large and uh, yeah, this is mainly because it contains The entire software stack uh from the linux kernel to the container and uh, and uh additionally, um we haven't uh investigated this overhead yet, but uh, I expect this is also because of the pre initialization Of the container the kernel is pre booted during the conversion. So it contains So much content in the memory and all of them are snap shorted and packaged into the wasm binary. So, uh, yeah But of course, but I expect uh, yeah, we can redo we can duplicate the contents between the snap shorted memory and the other Kind of images etc. So yeah, I hopefully reduce this size. Thanks for the question I've got a follow-up question to that Um, if you explored, um, you know, if I take my Go program and I compile it on my dependencies and I start and do like a from scratch Um, how small of a container have you made with this method? Or a way a container wasm Wasm and wasm tanner So when we use from scratch image, um, yeah, when we use from scratch image Yeah, uh, so When we use when we use from scratch image plus go compiler, the final content Is expected to be a single binary of the go Long agenda This approach adds Linux kernel and the bootloader emulator to that image. So, uh, yeah The final image will be, uh We'll contain this content. So maybe, uh, we'll be Fat enoughly, but uh Yeah, but uh, yeah, actually no exact number. I have currently so I expect we investigate more about performance Very interesting talk. Um, I understand, uh, the hypothetical use case, but I was wondering what was the, uh, Practical or direct immediate Problem entity encountered that they wanted to solve with this Thanks for the question The immediate problem problem Of mine, uh, of us Yeah Actually, this is kind of a research activity So, uh, I cannot say anything, uh, concrete, um, in this page But, uh, yeah, but hopefully, um, this approach is very generic one. So I expect, uh, this, uh, can be applied to Yeah, um Variet of use cases I expect I think thanks for the question I think we might turn for one more question But koei, I've got a set of containers, uh, that are go programs that have little sequel injects So maybe a lunch weekend. I'd love to see how small you can make. I've got a front scratch go. I'll point you out Brent, you got the last question Uh, so this is really interesting. I'm glad you're like playing around with it. Um Does this give you a path to essentially virtualize any existing Linux application in the browser? So the question is about, uh Um, is this a path for, uh Versalizing any apps on browser. So thanks for the question. Yeah, actually, this is the approach of converting containers to wasn't so Yeah, I expect, uh Yeah, anything can be containerized Uh, you can run on what's on as well But as of now, of course, no native access to devices, uh, on the machine Uh Yeah, always always, uh, the apps on browser need to, uh need Use, uh, browser APIs to access, uh, host devices. So, yeah, so Yeah, I expect, uh, I have some additional emulation will be needed for supporting, uh Non-common, uncommon devices accessing from the browser, but uh, but uh, but uh, but uh, definitely, uh Yeah, uh At the same way and every everything can be containerized Can run on browser as well by this approach, I expect But uh, yeah, but of course, um Yeah, we want, we want, uh, we want to test, uh for more applications, uh with this approach. So thanks for the question Okay, thank you very much. Please join me in thanking Koei for a wonderful talk