So, first of all, I will introduce myself, my name is Merlin, I'm a researcher at IMAC.
IMAC is a non-profit research center here in Belgium and I teach at Gange University, and
as part of my research, I work a lot on open source software, for example, with Ubuntu, but
today I will talk about my work on working on WebAssembly, together with the WC3 WebAssembly
system interface group, specifically I will talk about WebAssembly for IoT devices.
This might be a little bit counterintuitive, why do we want to get this web technology and use
it on IoT devices?
So let me start with this specific problem that we want to solve.
The average lifespan of a car in Europe is 30 years, so most cars run for at least 30 years.
This is mostly, they get bought mostly in Western Europe and then get a second hand run in
Eastern Europe, but still in Europe average lifespan of cars is 30 years.
30 years ago, this was the operating system that most of us were using, we were not
using one of the earlier versions of Linux, and so there also means that the chips in those
very old cars, the software on those chips was compiled on this kind of a system.
So how can you keep updating these cars?
How do you update the software on the car that uses a compiler that runs normally on Windows
95?
Well, the answer is basically, you update these things either, you don't update them or
you update them incredibly slowly.
There's a lot of software packages that are running in cars that are running on the
street at the moment, that are at least 10 years old, and if you look at for an example,
OpenSSL, anyone who knows even a little bit about security knows that running a 10 years
old version of OpenSSL is basically running everything unencrypted because this is full of
holes.
And we see, as a result of that, each year, the number of CVs impacting cars is rising
exponentially.
Now there is a lot of good use.
The good news is that the reason why the CVs specifically are rising exponentially is not
because suddenly cars become a lot more vulnerable, but it's because suddenly car manufacturers
are forced to actually start looking at software vulnerabilities inside of cars.
And so what they need in order to solve this is an easy way to update software on cars.
Otherwise, you have things like this, the Kia Challenge, where in the US a whole bunch
of kids on TikTok started showing each other how to break into a Kia car.
And Kia basically had to recall a whole bunch of vehicles, had to pay a very expensive law
suits, and still a lot of people in the US drive around with Kia cars that are vulnerable
to a tax that kids teach each other using TikTok.
The good news is that this kind of problem, the problem of constantly updating software
and having backwards compatibility and stuff like that, it's a problem that we actually
already solved.
Every single time you open Netflix, your web browser is basically downloading the Netflix app,
the latest version of the Netflix app, and is showing you and is running it on your device.
And this is also how companies like Netflix and Amazon and Disney can support thousands
and sometimes even tens of thousands of different devices with the exact same application.
A whole almost every single TV has a Netflix app and a Disney Plus app, and well, that
app itself is simply a browser.
The actual content that is being shown gets downloaded on the fly when the app starts up.
So my proposal is to use WebAssembly and WebAssembly system interface for embedded development,
for development of IoT devices, because first of all, you have binary device portability
across instructions at architectures.
This means that since a lot of car manufacturers right now are using multiple different
CPU architectures inside of their cars, and most of them are starting to switch to risk
fee.
So this doesn't actually impact their pipeline if they use WebAssembly because the same
binary runs on all of these devices.
Moreover, WebAssembly gives you support for much more programming languages and language
into rockerability.
If you talk to an embedded software engineer, most of them are using C. Some of them might
be using C++, very, very few of them might be using Rust, but this is an area where most
developers are using C. And this is not necessarily because C is such a great programming
language for this use case. This is specifically because many vendors of these embedded
devices simply give the developers a specific C compiler and say, okay, now you can use
this to compile a software on this device.
And if you want to run another programming language, well, that won't happen because this
compiler only supports C. WebAssembly also gives you forward compatibility with newer application
toolchains over multiple decades. So when we go back to this 30-year-old car, the original
toolchain was running on Windows 95.
Well, you can use modern toolchains to compile to WebAssembly that still runs on the very
first WebAssembly run times. You can do the exact, you will be able to do the exact same
thing in 30 years. It doesn't matter whether or not the device initially shipped with
whatever compiler, you can use the latest compiler to just compile to WebAssembly. And then
finally, this is a big one. Secure and sandbox execution of software, where other solutions
like containers or virtual machines do not fit. We have a prototype of this running on a microcontroller
with 265 kilobytes of memory. So you have fully sandboxed software, each different component
of your software is completely sandboxed on a microcontroller that cannot even run Linux,
let alone run containers. My opinion, this is really cool. But most importantly, in order
to have this technology available to work on embedded devices, these last two are incredibly
important. You need to have support for existing software. You need to be able to just
recompile your existing software to WebAssembly for this system to work, because none of
these companies want to throw away 50 years of investment in their software stack.
And secondly, you need to have near native efficiency and execution and compilation, specifically
because these devices have so little resources. So two years ago, the US version of
wasn't come, the WebAssembly conference. So people from Bush had this slide on the screen.
I was very happy with seeing this slide. How they explained it is WebAssembly can act
as a narrow waste of automotive software. Underneath WebAssembly, you have this very broad
area of ecosystem, of different devices, different operating systems. Some devices being
30 years old. And above WebAssembly, you have this continuously evolving ecosystem of applications
and software tool chains. And the thing that connects to the two is WebAssembly. WebAssembly
is the standard way to run applications on this very diverse set of hardware and operating
systems. So when they talk about challenges, I was very happy to see this, because this is
the exact thing that we are working on. We need to define unifying interfaces to the underlying
software layers. As the previous speaker also said, WebAssembly is completely sandboxed by the
full, so it cannot access your hardware. But we need to access hardware when you're running
own macro controllers. This is often the only thing that your software actually does is steer
other hardware. So, and then secondly, it's very important that this is standardized, because if
we create a proprietary non-standardized way to access hardware today, there is basically no chance that in
2030 years, the tool chains will still be compatible with it. We want this compatibility, so we need
this standardization of these interfaces. And that's what I call cyber-physical WebAssembly.
For those of you who don't know the buzzword, cyber-physical basically is a software system
that connects to hardware that drives hardware. And we can use WebAssembly for these cyber-physical
things. And so the goal is, well, yet the goal is just WebAssembly own IoT devices. We want,
for example, we want to secure a drivers, so that if you have a software supply chain vulnerability,
and one of your drivers is compromised, that attacking that driver still has an attacker that
has access to that driver still has limited reach to the entire device. This is not only important
for security, but also for stability. If one of your drivers crashes and your cyber-physical
system is a critical system in a car or something, you don't want your entire system to go
down just because one of the drivers crashed. Secondly, portable drivers. Right now it's quite
difficult to release products on the market because you need drivers for every single microcontroller,
every single operating system. Some of these are simply not supported. Well, with WebAssembly,
we can just compile our driver to WebAssembly using the standardized interfaces. And then it can
run basically anywhere. So this is basically what it looks like. You have this WebAssembly application
inside of the WebAssembly application. It's first of all an application and second of all,
then for example, your standard hardware extraction layer. For example, the rest hall, for example,
and then this connects using a standardized interface to the WebAssembly runtime.
Using the standardized interface, it basically says to the WebAssembly runtime. Okay, now contact this
sensor and write these values to those registers on that external device. And then the WebAssembly
runtime is responsible for translating these standardized abstracted calls into specific calls
for the specific operating system that we're running on. And so for the application, it doesn't
matter if it's running on Windows, on Linux, on a real-time operating system. The calls are exactly
the same, but then the runtime is responsible for translating these calls to host calls to the host
operating system. One of the interfaces that we built is was a USB. This standard is currently
in phase one as part of the WebAssembly system interface standards proposal and it's based on
basically the API of LipUSB. If you don't know any USB development, most of you are doing it with
LipUSB. It's basically the standard library in order to contact USB devices on any platform.
And so we modeled our standardized API very closely to LipUSB. So that first of all, it's incredibly
easy to compile LipUSB so that it uses this standard. And second of all, so that it's very easy
for existing applications to just use our interface instead of LipUSB itself.
The second interface that we've built is was a iSquared C. This is a standard that is currently
in phase two. And this is based on the embedded whole interface. And the whole is a rest library
in order to well contact iSquared C regardless of which operating system you're going. And so here
to we ensure compatibility with basically standard libraries so that it's very easy for these libraries
to use our API. And so it's very easy for applications that use these libraries to use our API.
We wrote about this work. We have a bunch of proof of concepts. We wrote about it and got a paper
accepted to the iTrippily, Noms conference about this. And what is very interesting and what gives
me a lot of hope for bringing this to the actual production environments is that the overhead
is an exceptionally low. For example, the additional overhead that we have with running a driver
and an application inside of WebAssembly to contact the USB device versus running it natively
is 0.007 milliseconds. Especially when you take into account that regular roundtrip times
for basically a USB window is much larger than that. And so often for most calls,
the overhead of WebAssembly is so small that you don't actually see it in your applications.
Troop with performance is exactly the same. We have great throughput. We have a little bit higher
reduction of the throughput, but still we have a great throughput. So we're still working on this.
We're still going to improve these standards. iSquart C hopefully maybe this year we're going to
move it to phase three. USB definitely this year we're going to move it to phase two. And we're
working on two other standards. One to access just GPIO just pins and one to access SPI devices
and also we're working on standardizing these. But the most exciting part of my presentation
and also the one that gives me the most stress is that we're going to try to give a demo.
Specifically what I'm going to demo is a WebAssembly application basically Puckman
running inside of a WebAssembly component together with a USB device driver for an Xbox controller
and that then uses a WebAssembly runtime in order to run everything. So let's take a look.
So the first thing I want to show is as you can see here we're basically running
a wasm time USB. This is just a modified version of wasm time that has an additional host component
to implement our USB support. This isn't yet upstream to wasm time itself. There's also something
that we're working on. And we run a WebAssembly application and you marate devices rust.wasm.
So it's just a rust implementation of LSU USB that we run as WebAssembly. And of course
so as you can see WebAssembly now sees all these USB devices. Now I'm going to connect
an Xbox controller via USB since we don't have a standard for Bluetooth yet only for USB.
Going to connect a Xbox controller via USB to my laptop.
And then I'm going to run the Pac-Man game. Let's see if this works. Yes.
So as you can see on the top these are the values of my Xbox controller that you see
which buttons are being pressed now press B. Now I press A. And then I can also play the game itself.
The dot in the middle is Pac-Man. Interestingly when I run it on my screen I don't see the flickering.
So I'm not entirely sure. But yeah this is the device driver for this USB controller.
It's running inside of WebAssembly next to the application itself. And it's using also wasm in order to
then show this screen to my terminal window. It's using the yeah some of the CLI standards in order
to show CLI output. That's it. I have one last slide.
So I have a lot of people to thank for this work. Sadly my colleague Michiel he couldn't
be here today because he is very very busy grading papers for some reason they put
our exam on Friday and we have to give in the results on Monday. So he's very busy grading papers.
And this work is also supported like many people here at Fossilam. This work is also supported
by the European Union. We got a very generous grant from the European Union to work on this.
So anyone here who is a European citizen thank you for your taxpayer dollars.
Are your taxpayer euros to fund me and everyone who's not a European citizen why are you not?
I see Federie is also here. He is one of the students that helped us with this
and who is now going to do PhD with us also working on WebAssembly.
So I think we have some time for questions.
So the question is what is wasn't time? Wasm time is a WebAssembly runtime.
The interesting thing about wasn't time is that it's a WebAssembly runtime without the actual web part.
So WebAssembly itself is just a bytecode format. It's just instructions for your CPU.
But then WebAssembly applications still needs to talk to the outside.
For example if WebAssembly is running in your browser it needs to access HTML.
It needs to be able to download files. In your browser WebAssembly does this by calling JavaScript.
In wasm time this JavaScript API is completely gone and the only API that is available is a
WebAssembly native API called the WebAssembly system interface and that's basically why the runtime
wasm time is so great for IoT devices and edge devices is because it's a lot smaller than the older
Node.es runtime for example that also have JavaScript.
And that's also why we see the amazing performance. That's why we see so little latency
because instead of having to call JavaScript to then contact the operating system we can just
contact the operating system almost directly using the WebAssembly system interface.
And all different times use case by day we want to be better than the older you see an issue
that where all of the runtime creates a situation where portability will not exist anymore
or because oh if I want to use IoT I need to use this runtime in these interactions and if I want
more cloud-naked stuff I need to use something like wasmx which has just a little bit too much
differences over here. Yeah so that's a very good question. The question is we have so many
different WebAssembly run times. Don't be risk losing compatibility. The idea is compile once run
it everywhere but then what if every runtime implements something else. That's a very good
question and the answer for that is that how these run times differ from each other is only in one
thing. It's which WebAssembly system interfaces these run times support. Some of them only support
the actual standardized interfaces and if you compile for such a runtime then you know that it will
work everywhere because these are the standardized interfaces. Some of them like our own wasm
time USB for example have not yet standardized or in progress standards interfaces and so if you
compile for a runtime like that well then obviously that's not going to work in other run times.
The interesting thing is that since the last version of the WebAssembly system interface they added
the concept of worlds. A world is basically a collection of all the interfaces that is supported
and so when you use WebAssembly on in the cloud or in the edge the cloud provider will basically
give you a description of a world that says these are all the interfaces that are supported by my
runtime and it's very easy you can just give that to your compiler and use that to compile your
replications and you will get errors if your application is using interfaces that are not supported
by that runtime and so the idea is not that every single runtime will support everything the idea is
that developers basically choose which world they target based on where they want their application
to run. Another thing I want to add is that WebAssembly is incredibly pluggable so even at a
runtime doesn't support an interface you could have another WebAssembly component that implements
that interface and so we also see some developments like Wazi Vert it's basically like in the old
browsers when many browsers didn't support and you with JavaScript features where we just implement
these features then in WebAssembly itself with less performance but your application will still run
even though the runtime doesn't support all the interfaces you need.
Performing target because I have not been imagining this working on a name.
So loads performing target for our iSquart C interface is a microcontroller that's 265 kilobytes
of RAM. The WebAssembly runtime itself on such a device takes about 60 kilobytes of storage space
and so I think that's the absolute lowest. We have in the bytecode aligns we have an embedded
special interest group where we are working on defining for most features what will be the lowest
and it seems like it will also be something like that. That's probably the lowest target.
Yeah that's a very good question. So the question is in the webAssembly component model
what kind of features would help us. So we are already using the webAssembly component model here
and what's very very nice is that the WebAssembly component model allows us to package a driver
and then an application as two separate components and the runtime just merges them and runs them
as a single WebAssembly application. The downside of the WebAssembly component model is that
when data crosses the boundary between two components or from a component to the host runtime
there you have copies and so I'm very very looking forward. The embedded sig is looking at
creating extensions to the component model that allow data transfer between components and
from a component to the host runtime without a copy. Something like man map or something like that
I think that that will be great and will lower our overhead even more.