 Okay, so we are back now, there will be a stream of lightning talk sessions. We have three of them, unless someone else steps forward. And the first speaker is Philippe. Hi, I'm Philippe from Khan Concepts. I'm involved in a nice project called Exploits, and you'll notice the D, not the T. What's Exploits? The long title is Exquisite Privacy Preserving Cost-Intuition Detection System. So what do we want to do? We want to have some cost-intuition detection system, or some machine, and we want to do some privacy-intuitive data collection and analysis. And it's a research project together with the University of Bresden and Leipzig and some other corporate partners. And sorry, I haven't had the time to translate it, but I will do my best. So that's the big overview. And what I'm currently working on is this gray area, which is F4RE. And another virtual machine monitor called the UBMM. There will also be some intrusion detection system hardware in front of the machine. So you have the virtual machine on one side, you have the virtual machine monitor below, and then you have the Linux running in that virtual machine. And if the Linux is attacked, then you want to buy some exploit by any attack vector, you want to detect that. And then you want to switch on some sensors to see, okay, now we get attacked and now we want to log as many information as possible about this attack to be able to essentially replay the attack. And to see, detect the vector of intrusion. And so, therefore, to detect all that, we have, the greatest plan is to have some sensors in the virtual machine. So it's not the concept that you are not detectable by the attacker. The concept is that you can even then detect the attacker and log what he's doing. So you have sensors in different levels in the operating system, and then as current module, you have some system services, and you have the application value, you have some logging capabilities, like, for example, the ZAH of the UT in Dresden, then you have two common points here, which profiles an application and it's something that you can detect that somebody is fiddling with that application. And then we get to the privacy preserving part, you have some posts running that virtual machine, and you have there the sensor injection, so you say, all right, I want to collect this data, that data, and the virtual machine monitor, and the kernel module, the Unix guest system supports the injection of that sensor so you can communicate and get more data, and then you extract the data and you want to keep the data as anonymous as possible to detect. So that's to be able to replay that attack. So that's ongoing research by the UT in Dresden's data security group, and then you want to anonymize the data and get it off the host because you don't want your, even in the case that your host is compromised, then you still want to keep the data and be able to replay the attack. The replaying thing is important, so you have a backend of the network, where you do forensic analysis, where you do graph analysis of the data you collected, then you may decide which sensors to switch on and off. And then there's the whole other part of that project, which targets that you can reuse the data and visualize that to allow a judge to understand what happened. So that the judge can understand who was the attacker, how did it, how did it, and so that you can come to a good sentence or a good outcome of that process. It's not only the micro-currency virtualization part of all this, it's also the privacy preserving. It has some database which allows to do data mining on encrypted data, and it's the visualization and explanation to a non-tacky person how this all happened. That's the project I'm going to work on. With our girls, we call our virtual machine monitor to the MD64 platform, so we have several virtualization solutions called our virtual machine monitor, which is for ARM, for MIPS, and now for MD64. We want to do some disrespecting and debugging of virtual machines in the shutting, and there's also some out-of-the-verting involved in the form of an FPGA, which can do memory accesses and development ideas that can do memory accesses and extract the data without helping to see you or develop a couple of problems including the photography and the anonymization and send it off to the database and we will observe it. Yeah, let's explore the problem. And if you have questions, I will be around later. Thank you. Thank you. Thank you. So our next speaker and the presenter of the next lightning talk is... Hello. So this is my head project. It's very experimental, very unfinished, so give that a mind. First, for a little motivation, I primarily work on Helanoff's micrometer operating systems. It supports many platforms. It also supports, still, I don't know why, in Toshida Slash 4G architecture. And the problem with that is that LLVM and by extension Rust doesn't support that architecture. The support that did exist is, I think, kind of broken and completely maintained. So it's a real option to use it for anything that needs to be reliable. And that means we have to find some way to get Rust on Helanoff's that can cope with this problem. One of the options is, of course, to just ignore the architecture. The other option is to ignore the Rust. But I opted for the option and I tried to solve this by building Rust to WebAssembly with its supports and then translate the WebAssembly to C and compile the C as you normally would in the application. WebAssembly is a binary distribution format developed primarily for use on the web. It is basically a virtual instruction set architecture. It has a set of instructions and it has execution semantics for Rust. It is designed to be secure, which is important for us because of reasons. And it is quite simple, actually. It is easy to work with and since it's generally a web technology, it is also basically lots and lots of users. And there are tools existing to work with this format. It is technically a very structural machine which, to some, evokes certain problems, but in this case, the stuckness of it is basically a representation metaphor. It doesn't really depend on there being a stack of values. It directly translates to static allocation. So you can just go through the code and make static variables from those slots on the stack. So this doesn't really make it any worse than, say, LLVM and compared to LLVM, this is portable, this is completely platform neutral, where LLVM basically doesn't even compile something to LLVM. You cannot run it on another platform than what it was compiled from. The LLVM bytecode is still specific to some architecture, even if it's not fully compiled yet. Whereas when you compile to WebAssembly, you really can run it everywhere. And it is exactly synoptics, exactly the behavior. And one of the important things is also that it basically supports checking memory accesses very simply. It's a built-in. So you don't have to worry about that. For example, if your system lacks memory management or, for example, you don't even have NMU, you can still WebAssembly problems, programs, binaries, compiled that you don't trust at all. You can be sure that they don't access anything they shouldn't trust. You already know there was a presentation before, and I've explained some of it. It has LLVM backend, so parts of WebAssembly, natively. And it is interoperable with CAPI, which when compiled to WebAssembly translates to imports. WebAssembly has a native concept of imported functions, which is what you can use here. So when you translate WebAssembly to C, you, as I said, set slots and add to local variables directly. There is no explicit set manipulation. Most instructions are not understood by the translator at all. I need to understand some basic things like control flow, for example, loops, branches, that kind of stuff. Most instructions, you just need to know how many spec slots they consume and how many are stored, which is currently 0 or 0.1. So, as you can see here, for example, the add instruction for the 64-bit integer gets translated to something like this. It just takes the variables corresponding to the stack slots, calls a function on it. That function, you can define it any way you want. You can make it an inline function in the same module as the generated code, for example, so that the compiler inlines it. And imported functions get translated to extensive functions, of course, so you can easily call functions and basically any API you want to expose or can expose with C code. For this, you can't directly pass pointers between the assembly code and native code, but you can make bindings, which take care of that. And this is part of the safety requirements that you can't just pass any pointer. That pointer is indexed to some local span of memory, and in the background. And as I said, the translator itself is very simple. It's just a few hundreds of lines of code, and it's quite crude, but GCC can optimize most of it away, so it doesn't have performance in it. And it is very flexible because, as I said before, most instructions are just calls to separate bindings, so you can define, for example, if you want to really check some operations, check number of accesses you can. If you don't want to check number of accesses, you also can. It just depends on the way you implement those C-shims. That's pretty much it. No more slides. I don't know how much time I spent. Okay, so that's it. If you have any questions, you can ask me later. Thanks for listening.