WEBVTT 00:00.000 --> 00:16.200 So, first of all, I will introduce myself, my name is Merlin, I'm a researcher at IMAC. 00:16.200 --> 00:22.680 IMAC is a non-profit research center here in Belgium and I teach at Gange University, and 00:22.680 --> 00:29.200 as part of my research, I work a lot on open source software, for example, with Ubuntu, but 00:29.200 --> 00:37.560 today I will talk about my work on working on WebAssembly, together with the WC3 WebAssembly 00:37.560 --> 00:45.760 system interface group, specifically I will talk about WebAssembly for IoT devices. 00:45.760 --> 00:51.200 This might be a little bit counterintuitive, why do we want to get this web technology and use 00:51.200 --> 00:53.840 it on IoT devices? 00:53.840 --> 01:00.560 So let me start with this specific problem that we want to solve. 01:00.560 --> 01:12.280 The average lifespan of a car in Europe is 30 years, so most cars run for at least 30 years. 01:12.280 --> 01:21.400 This is mostly, they get bought mostly in Western Europe and then get a second hand run in 01:21.400 --> 01:27.280 Eastern Europe, but still in Europe average lifespan of cars is 30 years. 01:27.280 --> 01:33.760 30 years ago, this was the operating system that most of us were using, we were not 01:33.760 --> 01:41.480 using one of the earlier versions of Linux, and so there also means that the chips in those 01:41.480 --> 01:49.200 very old cars, the software on those chips was compiled on this kind of a system. 01:49.200 --> 01:53.240 So how can you keep updating these cars? 01:53.240 --> 02:01.440 How do you update the software on the car that uses a compiler that runs normally on Windows 02:01.440 --> 02:02.440 95? 02:02.440 --> 02:10.320 Well, the answer is basically, you update these things either, you don't update them or 02:10.320 --> 02:15.320 you update them incredibly slowly. 02:15.400 --> 02:20.280 There's a lot of software packages that are running in cars that are running on the 02:20.280 --> 02:24.400 street at the moment, that are at least 10 years old, and if you look at for an example, 02:24.400 --> 02:30.120 OpenSSL, anyone who knows even a little bit about security knows that running a 10 years 02:30.120 --> 02:38.880 old version of OpenSSL is basically running everything unencrypted because this is full of 02:39.120 --> 02:41.120 holes. 02:41.120 --> 02:48.240 And we see, as a result of that, each year, the number of CVs impacting cars is rising 02:48.240 --> 02:50.240 exponentially. 02:50.240 --> 02:52.840 Now there is a lot of good use. 02:52.840 --> 02:58.480 The good news is that the reason why the CVs specifically are rising exponentially is not 02:58.480 --> 03:04.640 because suddenly cars become a lot more vulnerable, but it's because suddenly car manufacturers 03:04.720 --> 03:11.440 are forced to actually start looking at software vulnerabilities inside of cars. 03:11.440 --> 03:17.360 And so what they need in order to solve this is an easy way to update software on cars. 03:17.360 --> 03:23.440 Otherwise, you have things like this, the Kia Challenge, where in the US a whole bunch 03:23.440 --> 03:30.040 of kids on TikTok started showing each other how to break into a Kia car. 03:30.040 --> 03:36.920 And Kia basically had to recall a whole bunch of vehicles, had to pay a very expensive law 03:36.920 --> 03:44.800 suits, and still a lot of people in the US drive around with Kia cars that are vulnerable 03:44.800 --> 03:50.280 to a tax that kids teach each other using TikTok. 03:50.280 --> 03:58.120 The good news is that this kind of problem, the problem of constantly updating software 03:58.120 --> 04:02.640 and having backwards compatibility and stuff like that, it's a problem that we actually 04:02.640 --> 04:04.440 already solved. 04:04.440 --> 04:09.880 Every single time you open Netflix, your web browser is basically downloading the Netflix app, 04:09.880 --> 04:15.680 the latest version of the Netflix app, and is showing you and is running it on your device. 04:15.680 --> 04:23.920 And this is also how companies like Netflix and Amazon and Disney can support thousands 04:23.920 --> 04:30.360 and sometimes even tens of thousands of different devices with the exact same application. 04:30.360 --> 04:35.720 A whole almost every single TV has a Netflix app and a Disney Plus app, and well, that 04:35.720 --> 04:38.480 app itself is simply a browser. 04:38.480 --> 04:46.120 The actual content that is being shown gets downloaded on the fly when the app starts up. 04:46.120 --> 04:54.600 So my proposal is to use WebAssembly and WebAssembly system interface for embedded development, 04:54.600 --> 05:01.640 for development of IoT devices, because first of all, you have binary device portability 05:01.640 --> 05:04.480 across instructions at architectures. 05:04.480 --> 05:09.600 This means that since a lot of car manufacturers right now are using multiple different 05:09.600 --> 05:15.000 CPU architectures inside of their cars, and most of them are starting to switch to risk 05:15.000 --> 05:16.000 fee. 05:16.000 --> 05:20.680 So this doesn't actually impact their pipeline if they use WebAssembly because the same 05:20.680 --> 05:24.400 binary runs on all of these devices. 05:24.400 --> 05:30.880 Moreover, WebAssembly gives you support for much more programming languages and language 05:30.880 --> 05:32.960 into rockerability. 05:32.960 --> 05:39.560 If you talk to an embedded software engineer, most of them are using C. Some of them might 05:39.560 --> 05:45.520 be using C++, very, very few of them might be using Rust, but this is an area where most 05:45.560 --> 05:50.800 developers are using C. And this is not necessarily because C is such a great programming 05:50.800 --> 05:56.800 language for this use case. This is specifically because many vendors of these embedded 05:56.800 --> 06:02.200 devices simply give the developers a specific C compiler and say, okay, now you can use 06:02.200 --> 06:07.000 this to compile a software on this device. 06:07.000 --> 06:11.800 And if you want to run another programming language, well, that won't happen because this 06:11.800 --> 06:19.600 compiler only supports C. WebAssembly also gives you forward compatibility with newer application 06:19.600 --> 06:25.840 toolchains over multiple decades. So when we go back to this 30-year-old car, the original 06:25.840 --> 06:30.440 toolchain was running on Windows 95. 06:30.440 --> 06:38.000 Well, you can use modern toolchains to compile to WebAssembly that still runs on the very 06:38.000 --> 06:43.320 first WebAssembly run times. You can do the exact, you will be able to do the exact same 06:43.320 --> 06:51.560 thing in 30 years. It doesn't matter whether or not the device initially shipped with 06:51.560 --> 06:57.440 whatever compiler, you can use the latest compiler to just compile to WebAssembly. And then 06:57.440 --> 07:04.120 finally, this is a big one. Secure and sandbox execution of software, where other solutions 07:04.120 --> 07:11.120 like containers or virtual machines do not fit. We have a prototype of this running on a microcontroller 07:11.120 --> 07:19.640 with 265 kilobytes of memory. So you have fully sandboxed software, each different component 07:19.640 --> 07:25.720 of your software is completely sandboxed on a microcontroller that cannot even run Linux, 07:25.720 --> 07:31.560 let alone run containers. My opinion, this is really cool. But most importantly, in order 07:31.560 --> 07:37.760 to have this technology available to work on embedded devices, these last two are incredibly 07:37.760 --> 07:43.240 important. You need to have support for existing software. You need to be able to just 07:43.240 --> 07:49.080 recompile your existing software to WebAssembly for this system to work, because none of 07:49.080 --> 07:55.800 these companies want to throw away 50 years of investment in their software stack. 07:55.800 --> 08:02.880 And secondly, you need to have near native efficiency and execution and compilation, specifically 08:02.880 --> 08:14.040 because these devices have so little resources. So two years ago, the US version of 08:14.040 --> 08:20.280 wasn't come, the WebAssembly conference. So people from Bush had this slide on the screen. 08:20.360 --> 08:25.880 I was very happy with seeing this slide. How they explained it is WebAssembly can act 08:25.880 --> 08:32.360 as a narrow waste of automotive software. Underneath WebAssembly, you have this very broad 08:32.360 --> 08:39.240 area of ecosystem, of different devices, different operating systems. Some devices being 08:39.240 --> 08:45.600 30 years old. And above WebAssembly, you have this continuously evolving ecosystem of applications 08:45.680 --> 08:51.680 and software tool chains. And the thing that connects to the two is WebAssembly. WebAssembly 08:51.680 --> 09:00.080 is the standard way to run applications on this very diverse set of hardware and operating 09:00.080 --> 09:05.680 systems. So when they talk about challenges, I was very happy to see this, because this is 09:05.680 --> 09:12.400 the exact thing that we are working on. We need to define unifying interfaces to the underlying 09:12.400 --> 09:17.920 software layers. As the previous speaker also said, WebAssembly is completely sandboxed by the 09:17.920 --> 09:24.640 full, so it cannot access your hardware. But we need to access hardware when you're running 09:24.640 --> 09:30.320 own macro controllers. This is often the only thing that your software actually does is steer 09:30.320 --> 09:41.280 other hardware. So, and then secondly, it's very important that this is standardized, because if 09:41.600 --> 09:50.640 we create a proprietary non-standardized way to access hardware today, there is basically no chance that in 09:50.640 --> 09:59.200 2030 years, the tool chains will still be compatible with it. We want this compatibility, so we need 09:59.200 --> 10:06.160 this standardization of these interfaces. And that's what I call cyber-physical WebAssembly. 10:06.240 --> 10:11.600 For those of you who don't know the buzzword, cyber-physical basically is a software system 10:11.600 --> 10:19.920 that connects to hardware that drives hardware. And we can use WebAssembly for these cyber-physical 10:19.920 --> 10:26.160 things. And so the goal is, well, yet the goal is just WebAssembly own IoT devices. We want, 10:26.160 --> 10:32.720 for example, we want to secure a drivers, so that if you have a software supply chain vulnerability, 10:32.800 --> 10:39.600 and one of your drivers is compromised, that attacking that driver still has an attacker that 10:39.600 --> 10:45.920 has access to that driver still has limited reach to the entire device. This is not only important 10:45.920 --> 10:54.160 for security, but also for stability. If one of your drivers crashes and your cyber-physical 10:54.160 --> 10:59.360 system is a critical system in a car or something, you don't want your entire system to go 10:59.360 --> 11:08.720 down just because one of the drivers crashed. Secondly, portable drivers. Right now it's quite 11:08.720 --> 11:16.480 difficult to release products on the market because you need drivers for every single microcontroller, 11:16.480 --> 11:22.800 every single operating system. Some of these are simply not supported. Well, with WebAssembly, 11:22.800 --> 11:28.720 we can just compile our driver to WebAssembly using the standardized interfaces. And then it can 11:28.720 --> 11:38.080 run basically anywhere. So this is basically what it looks like. You have this WebAssembly application 11:38.720 --> 11:43.520 inside of the WebAssembly application. It's first of all an application and second of all, 11:43.520 --> 11:53.200 then for example, your standard hardware extraction layer. For example, the rest hall, for example, 11:54.000 --> 11:59.360 and then this connects using a standardized interface to the WebAssembly runtime. 12:01.600 --> 12:06.480 Using the standardized interface, it basically says to the WebAssembly runtime. Okay, now contact this 12:06.480 --> 12:15.200 sensor and write these values to those registers on that external device. And then the WebAssembly 12:15.200 --> 12:22.640 runtime is responsible for translating these standardized abstracted calls into specific calls 12:22.720 --> 12:27.200 for the specific operating system that we're running on. And so for the application, it doesn't 12:27.200 --> 12:33.200 matter if it's running on Windows, on Linux, on a real-time operating system. The calls are exactly 12:33.200 --> 12:39.200 the same, but then the runtime is responsible for translating these calls to host calls to the host 12:39.200 --> 12:48.960 operating system. One of the interfaces that we built is was a USB. This standard is currently 12:48.960 --> 12:59.040 in phase one as part of the WebAssembly system interface standards proposal and it's based on 12:59.840 --> 13:06.480 basically the API of LipUSB. If you don't know any USB development, most of you are doing it with 13:06.480 --> 13:12.960 LipUSB. It's basically the standard library in order to contact USB devices on any platform. 13:12.960 --> 13:18.800 And so we modeled our standardized API very closely to LipUSB. So that first of all, it's incredibly 13:18.880 --> 13:27.600 easy to compile LipUSB so that it uses this standard. And second of all, so that it's very easy 13:27.600 --> 13:33.520 for existing applications to just use our interface instead of LipUSB itself. 13:35.680 --> 13:42.640 The second interface that we've built is was a iSquared C. This is a standard that is currently 13:42.720 --> 13:53.840 in phase two. And this is based on the embedded whole interface. And the whole is a rest library 13:53.840 --> 14:00.240 in order to well contact iSquared C regardless of which operating system you're going. And so here 14:00.240 --> 14:08.240 to we ensure compatibility with basically standard libraries so that it's very easy for these libraries 14:08.320 --> 14:13.200 to use our API. And so it's very easy for applications that use these libraries to use our API. 14:15.440 --> 14:22.080 We wrote about this work. We have a bunch of proof of concepts. We wrote about it and got a paper 14:22.080 --> 14:30.240 accepted to the iTrippily, Noms conference about this. And what is very interesting and what gives 14:30.240 --> 14:37.840 me a lot of hope for bringing this to the actual production environments is that the overhead 14:37.840 --> 14:47.600 is an exceptionally low. For example, the additional overhead that we have with running a driver 14:47.600 --> 14:54.160 and an application inside of WebAssembly to contact the USB device versus running it natively 14:54.160 --> 15:04.880 is 0.007 milliseconds. Especially when you take into account that regular roundtrip times 15:04.880 --> 15:15.840 for basically a USB window is much larger than that. And so often for most calls, 15:15.840 --> 15:21.760 the overhead of WebAssembly is so small that you don't actually see it in your applications. 15:24.240 --> 15:29.920 Troop with performance is exactly the same. We have great throughput. We have a little bit higher 15:29.920 --> 15:37.600 reduction of the throughput, but still we have a great throughput. So we're still working on this. 15:37.600 --> 15:44.000 We're still going to improve these standards. iSquart C hopefully maybe this year we're going to 15:44.000 --> 15:48.880 move it to phase three. USB definitely this year we're going to move it to phase two. And we're 15:48.880 --> 15:57.600 working on two other standards. One to access just GPIO just pins and one to access SPI devices 15:57.600 --> 16:04.640 and also we're working on standardizing these. But the most exciting part of my presentation 16:04.640 --> 16:09.280 and also the one that gives me the most stress is that we're going to try to give a demo. 16:10.560 --> 16:16.720 Specifically what I'm going to demo is a WebAssembly application basically Puckman 16:17.360 --> 16:23.920 running inside of a WebAssembly component together with a USB device driver for an Xbox controller 16:24.960 --> 16:32.400 and that then uses a WebAssembly runtime in order to run everything. So let's take a look. 16:33.040 --> 16:46.240 So the first thing I want to show is as you can see here we're basically running 16:46.240 --> 16:52.160 a wasm time USB. This is just a modified version of wasm time that has an additional host component 16:52.160 --> 16:58.240 to implement our USB support. This isn't yet upstream to wasm time itself. There's also something 16:58.240 --> 17:04.720 that we're working on. And we run a WebAssembly application and you marate devices rust.wasm. 17:04.720 --> 17:11.840 So it's just a rust implementation of LSU USB that we run as WebAssembly. And of course 17:16.960 --> 17:23.280 so as you can see WebAssembly now sees all these USB devices. Now I'm going to connect 17:23.280 --> 17:30.560 an Xbox controller via USB since we don't have a standard for Bluetooth yet only for USB. 17:33.600 --> 17:38.720 Going to connect a Xbox controller via USB to my laptop. 17:42.800 --> 17:49.600 And then I'm going to run the Pac-Man game. Let's see if this works. Yes. 17:50.560 --> 17:56.880 So as you can see on the top these are the values of my Xbox controller that you see 17:57.440 --> 18:04.000 which buttons are being pressed now press B. Now I press A. And then I can also play the game itself. 18:04.000 --> 18:12.720 The dot in the middle is Pac-Man. Interestingly when I run it on my screen I don't see the flickering. 18:12.720 --> 18:19.760 So I'm not entirely sure. But yeah this is the device driver for this USB controller. 18:19.760 --> 18:28.000 It's running inside of WebAssembly next to the application itself. And it's using also wasm in order to 18:28.000 --> 18:38.480 then show this screen to my terminal window. It's using the yeah some of the CLI standards in order 18:38.480 --> 18:49.520 to show CLI output. That's it. I have one last slide. 18:56.800 --> 19:01.840 So I have a lot of people to thank for this work. Sadly my colleague Michiel he couldn't 19:01.840 --> 19:07.920 be here today because he is very very busy grading papers for some reason they put 19:08.000 --> 19:15.120 our exam on Friday and we have to give in the results on Monday. So he's very busy grading papers. 19:17.360 --> 19:22.480 And this work is also supported like many people here at Fossilam. This work is also supported 19:22.480 --> 19:30.000 by the European Union. We got a very generous grant from the European Union to work on this. 19:30.000 --> 19:34.480 So anyone here who is a European citizen thank you for your taxpayer dollars. 19:35.360 --> 19:41.360 Are your taxpayer euros to fund me and everyone who's not a European citizen why are you not? 19:43.520 --> 19:48.000 I see Federie is also here. He is one of the students that helped us with this 19:49.120 --> 19:55.280 and who is now going to do PhD with us also working on WebAssembly. 19:56.240 --> 19:58.080 So I think we have some time for questions. 20:05.120 --> 20:21.440 So the question is what is wasn't time? Wasm time is a WebAssembly runtime. 20:22.480 --> 20:28.800 The interesting thing about wasn't time is that it's a WebAssembly runtime without the actual web part. 20:29.680 --> 20:38.320 So WebAssembly itself is just a bytecode format. It's just instructions for your CPU. 20:38.880 --> 20:43.360 But then WebAssembly applications still needs to talk to the outside. 20:43.920 --> 20:48.400 For example if WebAssembly is running in your browser it needs to access HTML. 20:48.400 --> 20:54.640 It needs to be able to download files. In your browser WebAssembly does this by calling JavaScript. 20:55.600 --> 21:02.080 In wasm time this JavaScript API is completely gone and the only API that is available is a 21:02.080 --> 21:09.040 WebAssembly native API called the WebAssembly system interface and that's basically why the runtime 21:09.040 --> 21:18.080 wasm time is so great for IoT devices and edge devices is because it's a lot smaller than the older 21:18.480 --> 21:22.880 Node.es runtime for example that also have JavaScript. 21:23.600 --> 21:29.600 And that's also why we see the amazing performance. That's why we see so little latency 21:29.600 --> 21:36.320 because instead of having to call JavaScript to then contact the operating system we can just 21:36.320 --> 21:41.120 contact the operating system almost directly using the WebAssembly system interface. 21:48.080 --> 21:57.840 And all different times use case by day we want to be better than the older you see an issue 21:57.840 --> 22:06.000 that where all of the runtime creates a situation where portability will not exist anymore 22:06.000 --> 22:12.240 or because oh if I want to use IoT I need to use this runtime in these interactions and if I want 22:12.880 --> 22:19.280 more cloud-naked stuff I need to use something like wasmx which has just a little bit too much 22:19.280 --> 22:24.960 differences over here. Yeah so that's a very good question. The question is we have so many 22:24.960 --> 22:33.520 different WebAssembly run times. Don't be risk losing compatibility. The idea is compile once run 22:33.520 --> 22:39.840 it everywhere but then what if every runtime implements something else. That's a very good 22:39.840 --> 22:46.720 question and the answer for that is that how these run times differ from each other is only in one 22:46.720 --> 22:53.840 thing. It's which WebAssembly system interfaces these run times support. Some of them only support 22:53.840 --> 22:59.120 the actual standardized interfaces and if you compile for such a runtime then you know that it will 22:59.120 --> 23:06.800 work everywhere because these are the standardized interfaces. Some of them like our own wasm 23:06.800 --> 23:14.400 time USB for example have not yet standardized or in progress standards interfaces and so if you 23:14.400 --> 23:20.160 compile for a runtime like that well then obviously that's not going to work in other run times. 23:20.960 --> 23:27.760 The interesting thing is that since the last version of the WebAssembly system interface they added 23:27.760 --> 23:34.960 the concept of worlds. A world is basically a collection of all the interfaces that is supported 23:35.920 --> 23:42.640 and so when you use WebAssembly on in the cloud or in the edge the cloud provider will basically 23:42.640 --> 23:47.600 give you a description of a world that says these are all the interfaces that are supported by my 23:47.600 --> 23:53.440 runtime and it's very easy you can just give that to your compiler and use that to compile your 23:53.440 --> 23:59.680 replications and you will get errors if your application is using interfaces that are not supported 23:59.840 --> 24:06.160 by that runtime and so the idea is not that every single runtime will support everything the idea is 24:06.160 --> 24:12.560 that developers basically choose which world they target based on where they want their application 24:12.560 --> 24:21.200 to run. Another thing I want to add is that WebAssembly is incredibly pluggable so even at a 24:21.200 --> 24:27.360 runtime doesn't support an interface you could have another WebAssembly component that implements 24:27.520 --> 24:34.800 that interface and so we also see some developments like Wazi Vert it's basically like in the old 24:34.800 --> 24:40.960 browsers when many browsers didn't support and you with JavaScript features where we just implement 24:40.960 --> 24:46.560 these features then in WebAssembly itself with less performance but your application will still run 24:46.560 --> 24:49.600 even though the runtime doesn't support all the interfaces you need. 24:57.600 --> 25:02.800 Performing target because I have not been imagining this working on a name. 25:04.400 --> 25:12.880 So loads performing target for our iSquart C interface is a microcontroller that's 265 kilobytes 25:12.880 --> 25:24.080 of RAM. The WebAssembly runtime itself on such a device takes about 60 kilobytes of storage space 25:24.720 --> 25:32.800 and so I think that's the absolute lowest. We have in the bytecode aligns we have an embedded 25:32.800 --> 25:38.880 special interest group where we are working on defining for most features what will be the lowest 25:38.880 --> 25:45.760 and it seems like it will also be something like that. That's probably the lowest target. 25:54.080 --> 26:13.680 Yeah that's a very good question. So the question is in the webAssembly component model 26:14.560 --> 26:20.880 what kind of features would help us. So we are already using the webAssembly component model here 26:21.360 --> 26:26.400 and what's very very nice is that the WebAssembly component model allows us to package a driver 26:27.440 --> 26:33.040 and then an application as two separate components and the runtime just merges them and runs them 26:33.040 --> 26:40.000 as a single WebAssembly application. The downside of the WebAssembly component model is that 26:40.000 --> 26:45.760 when data crosses the boundary between two components or from a component to the host runtime 26:45.840 --> 26:53.040 there you have copies and so I'm very very looking forward. The embedded sig is looking at 26:53.040 --> 26:59.920 creating extensions to the component model that allow data transfer between components and 26:59.920 --> 27:04.960 from a component to the host runtime without a copy. Something like man map or something like that 27:04.960 --> 27:09.040 I think that that will be great and will lower our overhead even more.