Microkernel lightning talks
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Feske, Norman
Due to a cancellation, the Microkernel devroom will offer a lightning talk session in the field of Microkernels, Unikernels, and component based systems on Sunday from
 I would like to show you how our core uses to look like everyday at new depths. So this system is called Cooled OS. And maybe if you like you can download it from our website. So it's right here. And the basic idea is that it comes on a small USB storage device. The disk image is just about 25 megabytes in size. So it's a really tiny image. I know my laptop I have only one big file system, only data on the laptop. And there's no OS installed except for this tiny thing that I plug in. And the idea was that this is so tiny that you can in principle also put it into some kind of flash memory in the Windows. That would be pretty cool. So now I will just start up the routine. I can turn it around so you can see that it's doing something until the screen goes up. So it takes a while to get the logo. And so now it's fetching data from the USB stick. And here we are in the geno world. So you see it puts up pretty quickly once you pass the logo. So at this point when you see the first live sign of G-Note, there are already about 60 components running. So in contrast with your Google Look system and your start kernel, you have one big program with everything built in. But here we have these tiny Cutshires, these sandboxes. And each tiny functionality like the USB drive or the PS2 drive or all the different parts of the system, they are each sandbox that you get a component. The system has some kind of user interface that you see right now. And this allows you to basically be the boss of the system. So you as a user are the boss. And this interface here is called LightZenfather, which is a German term for a sophisticated control instrument. Not for unsophisticated user, but for someone who knows what he's doing. Maybe I can give you a slide over to you for how the system is constructed. So this is just boring. This one is interesting. So what we have in this USB stick is basically the system, the booted microkernel, about 10,000 code. We are using the kernel of this gentleman over there, that's with NOVA hypervisor. And the static system comes with a smaller static system booted on top of the kernel. And then on top of this static system, three dynamic systems are established. So this is always the same, but what we have up there is becoming dynamic. So for example, the driver system is dynamic, because when we boot a USB stick, we don't know how the hardware is. Is there an intergraphics or is it not an intergraphics? So we have some kind of runtime decision. And this takes place in this driver sub-system. Then we have the LightZenfather. This is basically the user interface to interact with the system. And then we have the place yield for the user. The actual useful stuff happens, like the programs that I want to execute. And what you see in this graph in the middle is basically the current state of the runtime, so on the right part of the system. And you see, when I started this computer, quite a few components were already started. And for example, I can switch between the LightZenfather and the real desktop using F12. So when you press this button, you can see now you have this bot mode, basically. And now we have our desktop. And so we can also interact with these windows and do some, this is for example, a small unit-like environment, custom build. And you can at any point in time, begin control over all the system, record as of what happens in the runtime. You can always get back to the view. And yeah, this allows us, for example, also to add new components. So for example, I can, what I usually do when I'm working, I fire up a virtual machine. And you know, this is to tell me, the virtual machine requires some kind of networking. So I say, okay, let's try out the Wi-Fi. So I click on this button, what happens here is you see the Wi-Fi driver enters the picture that's over here. And we have a sneak router. So this sneak router is basically something like a nut device. It virtualizes our network, but it's all virtual on our system here. So you see, the Wi-Fi driver is actually running, has scanned the network, and we have this custom legacy and try to connect to this. And so we have in the background our virtual machine, pull it up. So you see it here. This is just a Linux VM. And the virtual machine is basically a port of virtual box for G-Node. So it is able to execute all the guests that can be run in virtual box. And this is basically how I spend most of my day really inside this virtual machine. So I have all the productive work. Oh, yes. Sorry. Okay. Thank you. So most of the development work still happens inside this VM, but we are now in a process to move the different things outside the VM into native G-Node components. To give you a big overview about how the system works under the hood, let me show this the overview of the static system. Because I think that's quite elegant and quite a different approach compared to traditional operating systems. So the static system basically contains this GUI server, so the guy who multiplexes our display that you have seen already. And then there are basically two in-memory-fi systems. So these are basically RAM-fi systems, a bit like 10FS or Linux. They are just empty at the start-up. And in this case of the configuration-fi system, there is some initial content fetched from the USB stick, and this is put in there as part of the image. And the purpose of these two-fi systems is that on the one side, this 3.FS aggregates all the state of the components. So the different components, they talk sometimes interesting things. So for example, I give you an example, the wireless driver is running, and from time to time, the wireless driver just tells us what it finds. So in the light-central, we can basically access those files directly. You see over there the configFS, and it's a bit small, right? Maybe I should increase the font size a bit. So let's put the configFS to good use now. So by default, the system tries to scale the fonts according to the screen size, but you can override it as a user. So I can, for example, say I want to have this managed font config as a basis for a manually managed configuration. So I copy this configuration file basically to... Oh, sorry. Yeah. To this place. And now I can basically edit this configuration. And here you see basically a font configuration. The funniest thing is that those fonts are actually implemented as a file system. So we have a true type file system, and the font rendering happens in the file system. And the font sizes are basically just amount attributes for those files. So what we have here, for example, for this monospace text, let's make this a bit bigger. I can say, okay, I want to have this one. And now we have changed the file system to mounting attributes. The true type file system is remounted and picked up by the different components. Sounds a bit esoteric, but it's surprisingly useful. The cool thing is by putting this into a separate component, in a separate file system kind of component, the actual application, like the terminal, doesn't even have to link against the font library. There's no need to link against this free type. All the complexity goes away, and we can just obtain the ready rendered glyphs from the file system. But okay, that's just the detail. Yeah, let's go back to the wireless topic. I explained that there is this report file system, and this contains all kinds of interesting information. For example, we can take a look at what the Wi-Fi driver reported about the Wi-Fi access points. So you see here, these are the Wi-Fi access points that are reported. And what you have seen before here in this area is just a view on this report, nothing more. And another example, if you want to look what the inter-graphics driver is detecting, we can say, okay, let's look at the driver subsystem, and there we have a dynamic part where the inter-driver is running, and then the inter-driver has this report generated for us, and you can see which connectors there are. And conversely, if you want to modify the configuration of one of these components, we can, you guess it, I guess, modify the configuration as like the frame buffer file system here. So sometimes it's useful to basically enforce a different screen size for, let's say, giving a talk. So here I'm really reconfiguring the low-level graphics driver that normally also sits in the kernel, and what we see here, it works. And even you can even see that the fonts are updated in size of the fonts. And the bottom line is that there is only one interface for these configuration problems. Well, in a little system you have this X-Runder interface for the graphics, and you have a completely different interface for the wireless or for the network configuration. Here everything is one coherent concept, and this goes really far. So for example, let's take a look into the configuration of the nitpicker GUI server. So this is under config nitpicker. This is basically the security policy of the low-level GUI server. And what you see here is basically there are a bunch of security domains. So for example, there is this mouse pointer. It's a dedicated security domain. And as a matter of fact, the program that draws the mouse pointer doesn't know where on screen the mouse pointer is located. We just say that this domain has a coordinate origin pointed at that is the pointer. So the program always draws at 0, 0, and we get the mouse pointer there. And we can do funny things like, for example, I can say, ah, we have this domain light-central. So let's use this as a mouse pointer. Like you can do the same here. And now we have the light-central as the mouse pointer. So you get the idea that the whole system is very, you can model it on your fingertips. And that's also the reason why the whole thing is called Sculpt, because you have like a sculpture. You start with a generic thing on the USB stick, and then you can model it or modify it, and save the result on the USB stick again, and then you have your custom system. Do I have some more minutes or? It depends on if you like me, you can go on. Oh, it's amazing. Okay, thanks a lot. Okay, another unique point about the sculpture system is that we of course want to extend it. So we don't have all the software on the USB stick. We want to install new things. We don't know who provides the thing. For example, I want to install a game developed by Emery. But I also want to maybe add some new software, like a new version of Soul in the future, provided by you. And so we need some way of deploying and installing software on Sculpt. And so last year I already talked a bit about how this can be implemented. And let me just recapture the general idea. This was basically the idea. So just think about installing and updating software in our today's systems. You have usually some kind of package manager or updates process that has ultimate power over the whole system. So if you install something on the deviant with up get or something like that, you can basically cause any kind of damage. So like for example, when Microsoft distributes deviant packages, it can happen that bin s h is disappearing. Things like that. And on some of those distributions sometimes things happen like an afforded archive can basically touch any part of the system. So you have a program of ultimate power. And this is basically connected to the network. And the program is also super complex because it uses things like GPG for verifying the signatures. It has to extract the archive users, SSL and so on. So there's a software stack of hundreds of thousands lines of code involved in these programs. So you have super high complexity. You have network connectivity and you have ultimate power. What could possibly go wrong? Yeah, so and the idea was we could do better by basically leveraging the sandboxing features of G-node. And the idea is basically to have to cut this, to break this software installation problem down into individual problems and address each individual problem by a dedicated G-node system and then very quickly change this G-node systems on the fly. So basically the problems are that we first want to find out what software is actually missing. What do we need to install? Then we have to find out where to get it, the software and also how to verify it. Once you notice, we have to download it from this location. Then when the download is complete, we have to basically check the signatures and if the integrity is intact, we can extract it. And then we have new content and we can look again if there's something missing. So this is like going in iterations. And now for each of the steps, we can look how to accomplish this. You see that in the center of the whole thing, there's this download manager. So this is the component that orchestrates everything. And this is really critical. This must be protected by all means. And this download manager does not do any dirty work. It is even picky about touching files on the fly system. It won't do that. Instead, for example, to find out what's missing, it basically uses a companion G-node subsystem and configures this one to spawn a kind of minion kind of component that does the dirty work for this guy. So the download manager just tells this one, please find out what's missing. And so this guy starts walking around looking at this part of the fly system and finds out, ah, I need this and this new content, this is missing. And reports this back to the download manager using this report interface. And next step, the report query component is basically then commissioned to work to find out where to get this software from. And once this information is cleared, we know, OK, we want to have this content and we can download it from this and this place. And now let's download it. And here things get really dangerous because now we have the network connectivity over here. And we have now a whole software stack for downloading the content, yeah, like the TCPIP stack ported from Linux, SSL, QL, and so on. And so this is hugely complex. That's a complex thing. It's connected to the network, so we assume it's compromised. So an attacker can go from here inside there and it could also land in this kind of place of the fly system. Yeah, so this is basically our assumption that this is already infected. So the next step, we completely cut off the network connection and replace this whole networking stack with another component, with this verify component. And this one only has access to this part of the fly system. And while doing the verification, no other component touches this area. So there could be no network application writings to it. But so we know that the result of the verification is basically integer. So in the end, we have this decision, good or bad. And we can basically then go on and extract it. And here it's another consideration. Let's say I download some software from a company I don't trust. I still want to use this software, like for example Adobe Flash Player or something like that. So I want to use the software, but I don't trust Adobe. So if the signature is right, I'm still not happy because, yeah, I don't trust them. So what I want to enforce is that everything that comes from Adobe gets placed in a dedicated area on my hard disk that is labeled Adobe and I can wipe it off the hard disk at any time. And this can be accomplished by just having this change root component here. Basically it intercepts this fly system session here and the extraction program can extract content only to this particular part of the fly system. So that means that you can install with G-Node, with this root less, you can install peerless applications from untrusted parties. And we know that this is integer, but we can, of course, we check the signatures. But we can just do this. And once we deploy the applications, we still can decide what kind of resources to hand out to the application. So for example, if for some reason the Flash player would like to access our config FS, we can still just route the session to an empty RAM FS and then virtualize everything. So, okay, now enough talk. Maybe I can, I am happy to show that it really works. Let's see if we have some component here. It's not yet installed. Let's, for example, click on this one. So now the system will probably find out that there is no, it's not installed yet. This program I have clicked on. And now here you see that it now fetches the content from for this QT application. And... Yeah, yeah, don't worry. But it's working. No, we are at the point of slow micro-conveyor systems, right? But I think it's not slow, really. You can use it and it's practical for day-to-day work. So, it's the code switch that you want to... Would you want to tell something about Hedermas, right? Yeah, I'd like to attend a minute. Yeah, that's okay. Okay. No, maybe I... Yeah, if you let me speak, then I will just go on. That's right. So, here we have this QT application. So, you see here that now we have just installed and deployed this application. And so, this is some basic blurs, the line between deploying and installing. It's basically what's on the hard disk, the depot on the hard disk is basically just a cache. We can wipe it off and we can click again on the item and it will install what's needed on demand. Okay, that's the point where I would like to wrap up. Thanks for the chance to present it here. And if you'd like to look at it, you can find it on our geno.org site. And, yeah, that's it. Thanks. Thank you. Thanks. Thanks. And that looks more unmuted. Okay, hello. This is me again today. I'm Jakub from Kern Concept. But this time I am stepping in for a friend who was originally supposed to deliver this much longer talk about Hellenos and the evolution of its file system layer. Unfortunately, he fell ill. So I would like to take this opportunity and only give a short Hellenos update in the remaining eight or so minutes. So for those of you who don't know how Hellenos looks like and what it is, I can... Maybe I can show you a short demo right from the beginning. So I've just started off Hellenos. That's interesting. So this is Hellenos running on AMD64, but we also support some other architectures like Spark64, Itanium, ARM32. Today the micro-cranel in the room had a visitor who is no longer here, I guess, Petr Pavlu, and who suddenly appeared from nowhere and wrote a message to our mailing list saying, by the way, here is a port of Hellenos to 64-bit ARM and I've been working on it for four years. So you can, of course, control Hellenos the usual way. Just don't get confused or don't get mistaken. This is not a Linux distribution even though some of the commands might give you that impression. But everything that I'm running right now... This is an OS. Right, so this was the audio stack. Everything I'm running by now was written by us or some students that we were supervising. Hellenos is probably one of the very few micro-cranel projects that actually writes its device drivers and file systems and networking stacks itself. So to contrast this with L4RE that I spoke about previously, where the way would be to take some existing component, maybe a whole VM which runs the networking stack or provides some device drivers, we would write them ourselves. And especially this is true for the gentleman who was supposed to deliver this talk in the first place. So we can do also some fancier stuff in our group. But I don't think we have that much time to play with that. Just ping the local host. We can't ping a local host. We can ping a non-local host like on QMood. It's a different number. It's like 10. Or 15? Is it 15? Never mind, this is supposed to work. But in general you can ping something out of the... something which is listening on the network interface, but there is no kind of link to the local host. You can't ping local host. That's like a small alliance. So enough with the demo itself. Let's just see what we have done since last was done. So there was a release in July. Hellenos07.2 was released. Some of the highlights are a rewrite of the USB stack. We had a group of students who wrote a new USB 3.0 stack by adding the XHCI controller and basically rewriting the stack from the most part. We did some device drivers like Verti-onet. Another student worked on adding C++14 support for C++14. Finally, did something about our Lipsy compliance because when we started many years ago, we were... I think Norman describes that as a cowboy attitude. We were like, yeah, we can do everything. We won't be compatible with anything. So that changed a little bit. So nowadays we tend to draw the line at the C, standard C library, and try to be compatible on that level and throw all the other legacy away. I did some capability work for which I would refer you to my talk from last was done. Irka, the original presenter of this, he worked on automatic volume mounting. So whenever Hellenos spots file system which has a volume, it automounts it. That's kind of like when you have a flash disk and plug it into your Linux or Windows computer, it automatically gets mounted. So this is something like that. Then in another release which happened in December, we switched to our custom GCC target which already managed to slightly backfire. But other than that, it's a pretty good idea because now we have the whole thing that builds Hellenos under our control and there are no surprises in terms of what the compiler can do if we squat on the Linux target that we were using previously. We had some improvements in the kernel. Basically there is a new red-black tree-based data structure which replaced the existing Avia and B-plus trees. It was heavily used in memory management. The new data structure has just slightly better API which is more favorable to memory management because it does not allocate anything on its own. You have to pass it memory. Then we threw out a couple of things like the complete RCU and concurrent hash table implementation because we are not using it actively and there were some bugs and the thing was not maintained and in the spirit of this new phenomenon, was it Marie Condé? His name. It didn't spark joy so we completely removed RCU and CHD. Then the work on the volume manager and the volume layer continued. The system is trying to preserve slash W as something which is always mounted with the file system on which HLENOS was installed. Then there were some fixes. Also the capability work continued. Some new packages. Now you can install a package which is a ZX Spectrum emulator and there is another one which is not a package yet but rather a branch of HLENOS on GitHub which is a NES emulator. If you happen to own some of the ROMs, you can even play some retro games on HLENOS right now. As for what new features were added to HLENOS after the release, unlike before when we only supported dynamic linking on IA32, Irka, the guy who should have been here, he also added the NB64 ARM32 power PC and Spark 64 dynamic linking and I believe that he is working on the remaining architectures right now. I show you the PCI utility at the beginning so that's just a utility which allows you to see what PCI devices were discovered by the device driver framework and I already told you about the pending ARM64 port of HLENOS. As for the plans, finish dynamic linking support. Martin is working on risk 5 support that would nicely complement our collection of supported architectures. Of course there is still a lot of work to be done on the capability front. As for this file system management, I think that translates to changes that are related to this file system work and volume management to make the system more user friendly. That's one of Irka's goals. And also in the same vein and the same category, dynamic and persistent and work configuration, I'm also suspecting he wants to rewrite the graphical user interface that I showed you at the beginning. We revived our doxigen documentation which was non-existent for a long time and probably the last thing, yes, the last thing I would like to mention is there is going to be a new virtual block driver because we realized that by having one we would actually allow some more exotic architectures like Spark64 and PowerPC and probably also some ARM ones to have an actual block driver which they don't have right now and we are constantly struggling with making the boot image small so that it fits and can be booted from. And having a block device driver is one of the things that we need to switch to a fully supported scheme like we have on X86 where we can boot from an installed system. So, virtual block driver is coming and thank you for your attention. applause applause applause applause applause applause applause applause
 I would like to show you how our core uses to look like everyday at new depths.  So this system is called Cooled OS.  And maybe if you like you can download it from our website.  So it's right here.  And the basic idea is that it comes on a small USB storage device.  The disk image is just about 25 megabytes in size.  So it's a really tiny image.  I know my laptop I have only one big file system, only data on the laptop.  And there's no OS installed except for this tiny thing that I plug in.  And the idea was that this is so tiny that you can in principle also put it into some kind of flash memory in the Windows.  That would be pretty cool.  So now I will just start up the routine.  I can turn it around so you can see that it's doing something until the screen goes up.  So it takes a while to get the logo.  And so now it's fetching data from the USB stick.  And here we are in the geno world.  So you see it puts up pretty quickly once you pass the logo.  So at this point when you see the first live sign of G-Note, there are already about 60 components running.  So in contrast with your Google Look system and your start kernel, you have one big program with everything built in.  But here we have these tiny Cutshires, these sandboxes.  And each tiny functionality like the USB drive or the PS2 drive or all the different parts of the system,  they are each sandbox that you get a component.  The system has some kind of user interface that you see right now.  And this allows you to basically be the boss of the system.  So you as a user are the boss.  And this interface here is called LightZenfather, which is a German term for a sophisticated control instrument.  Not for unsophisticated user, but for someone who knows what he's doing.  Maybe I can give you a slide over to you for how the system is constructed.  So this is just boring. This one is interesting.  So what we have in this USB stick is basically the system, the booted microkernel, about 10,000 code.  We are using the kernel of this gentleman over there, that's with NOVA hypervisor.  And the static system comes with a smaller static system booted on top of the kernel.  And then on top of this static system, three dynamic systems are established.  So this is always the same, but what we have up there is becoming dynamic.  So for example, the driver system is dynamic, because when we boot a USB stick, we don't know how the hardware is.  Is there an intergraphics or is it not an intergraphics?  So we have some kind of runtime decision.  And this takes place in this driver sub-system.  Then we have the LightZenfather.  This is basically the user interface to interact with the system.  And then we have the place yield for the user.  The actual useful stuff happens, like the programs that I want to execute.  And what you see in this graph in the middle is basically the current state of the runtime,  so on the right part of the system.  And you see, when I started this computer, quite a few components were already started.  And for example, I can switch between the LightZenfather and the real desktop using F12.  So when you press this button, you can see now you have this bot mode, basically.  And now we have our desktop.  And so we can also interact with these windows and do some, this is for example, a small unit-like environment, custom build.  And you can at any point in time, begin control over all the system, record as of what happens in the runtime.  You can always get back to the view.  And yeah, this allows us, for example, also to add new components.  So for example, I can, what I usually do when I'm working, I fire up a virtual machine.  And you know, this is to tell me, the virtual machine requires some kind of networking.  So I say, okay, let's try out the Wi-Fi.  So I click on this button, what happens here is you see the Wi-Fi driver enters the picture that's over here.  And we have a sneak router.  So this sneak router is basically something like a nut device.  It virtualizes our network, but it's all virtual on our system here.  So you see, the Wi-Fi driver is actually running, has scanned the network,  and we have this custom legacy and try to connect to this.  And so we have in the background our virtual machine, pull it up.  So you see it here.  This is just a Linux VM.  And the virtual machine is basically a port of virtual box for G-Node.  So it is able to execute all the guests that can be run in virtual box.  And this is basically how I spend most of my day really inside this virtual machine.  So I have all the productive work.  Oh, yes.  Sorry.  Okay. Thank you.  So most of the development work still happens inside this VM,  but we are now in a process to move the different things outside the VM into native G-Node components.  To give you a big overview about how the system works under the hood,  let me show this the overview of the static system.  Because I think that's quite elegant and quite a different approach compared to traditional operating systems.  So the static system basically contains this GUI server,  so the guy who multiplexes our display that you have seen already.  And then there are basically two in-memory-fi systems.  So these are basically RAM-fi systems, a bit like 10FS or Linux.  They are just empty at the start-up.  And in this case of the configuration-fi system,  there is some initial content fetched from the USB stick,  and this is put in there as part of the image.  And the purpose of these two-fi systems is that on the one side,  this 3.FS aggregates all the state of the components.  So the different components, they talk sometimes interesting things.  So for example, I give you an example, the wireless driver is running,  and from time to time, the wireless driver just tells us what it finds.  So in the light-central, we can basically access those files directly.  You see over there the configFS, and it's a bit small, right?  Maybe I should increase the font size a bit.  So let's put the configFS to good use now.  So by default, the system tries to scale the fonts according to the screen size,  but you can override it as a user.  So I can, for example, say I want to have this managed font config  as a basis for a manually managed configuration.  So I copy this configuration file basically to...  Oh, sorry.  Yeah.  To this place.  And now I can basically edit this configuration.  And here you see basically a font configuration.  The funniest thing is that those fonts are actually implemented as a file system.  So we have a true type file system, and the font rendering happens in the file system.  And the font sizes are basically just amount attributes for those files.  So what we have here, for example, for this monospace text,  let's make this a bit bigger.  I can say, okay, I want to have this one.  And now we have changed the file system to mounting attributes.  The true type file system is remounted and picked up by the different components.  Sounds a bit esoteric, but it's surprisingly useful.  The cool thing is by putting this into a separate component,  in a separate file system kind of component,  the actual application, like the terminal, doesn't even have to link against the font library.  There's no need to link against this free type.  All the complexity goes away, and we can just obtain the ready rendered glyphs from the file system.  But okay, that's just the detail.  Yeah, let's go back to the wireless topic.  I explained that there is this report file system,  and this contains all kinds of interesting information.  For example, we can take a look at what the Wi-Fi driver reported about the Wi-Fi access points.  So you see here, these are the Wi-Fi access points that are reported.  And what you have seen before here in this area is just a view on this report, nothing more.  And another example, if you want to look what the inter-graphics driver is detecting,  we can say, okay, let's look at the driver subsystem,  and there we have a dynamic part where the inter-driver is running,  and then the inter-driver has this report generated for us,  and you can see which connectors there are.  And conversely, if you want to modify the configuration of one of these components,  we can, you guess it, I guess, modify the configuration as like the frame buffer file system here.  So sometimes it's useful to basically enforce a different screen size for, let's say, giving a talk.  So here I'm really reconfiguring the low-level graphics driver that normally also sits in the kernel,  and what we see here, it works.  And even you can even see that the fonts are updated in size of the fonts.  And the bottom line is that there is only one interface for these configuration problems.  Well, in a little system you have this X-Runder interface for the graphics,  and you have a completely different interface for the wireless or for the network configuration.  Here everything is one coherent concept, and this goes really far.  So for example, let's take a look into the configuration of the nitpicker GUI server.  So this is under config nitpicker.  This is basically the security policy of the low-level GUI server.  And what you see here is basically there are a bunch of security domains.  So for example, there is this mouse pointer.  It's a dedicated security domain.  And as a matter of fact, the program that draws the mouse pointer doesn't know where on screen the mouse pointer is located.  We just say that this domain has a coordinate origin pointed at that is the pointer.  So the program always draws at 0, 0, and we get the mouse pointer there.  And we can do funny things like, for example, I can say, ah, we have this domain light-central.  So let's use this as a mouse pointer.  Like you can do the same here.  And now we have the light-central as the mouse pointer.  So you get the idea that the whole system is very, you can model it on your fingertips.  And that's also the reason why the whole thing is called Sculpt, because you have like a sculpture.  You start with a generic thing on the USB stick, and then you can model it or modify it,  and save the result on the USB stick again, and then you have your custom system.  Do I have some more minutes or?  It depends on if you like me, you can go on.  Oh, it's amazing.  Okay, thanks a lot.  Okay, another unique point about the sculpture system is that we of course want to extend it.  So we don't have all the software on the USB stick.  We want to install new things.  We don't know who provides the thing.  For example, I want to install a game developed by Emery.  But I also want to maybe add some new software, like a new version of Soul in the future, provided by you.  And so we need some way of deploying and installing software on Sculpt.  And so last year I already talked a bit about how this can be implemented.  And let me just recapture the general idea.  This was basically the idea.  So just think about installing and updating software in our today's systems.  You have usually some kind of package manager or updates process that has ultimate power over the whole system.  So if you install something on the deviant with up get or something like that, you can basically cause any kind of damage.  So like for example, when Microsoft distributes deviant packages, it can happen that bin s h is disappearing.  Things like that.  And on some of those distributions sometimes things happen like an afforded archive can basically touch any part of the system.  So you have a program of ultimate power.  And this is basically connected to the network.  And the program is also super complex because it uses things like GPG for verifying the signatures.  It has to extract the archive users, SSL and so on.  So there's a software stack of hundreds of thousands lines of code involved in these programs.  So you have super high complexity.  You have network connectivity and you have ultimate power.  What could possibly go wrong?  Yeah, so and the idea was we could do better by basically leveraging the sandboxing features of G-node.  And the idea is basically to have to cut this, to break this software installation problem down into individual problems  and address each individual problem by a dedicated G-node system and then very quickly change this G-node systems on the fly.  So basically the problems are that we first want to find out what software is actually missing.  What do we need to install?  Then we have to find out where to get it, the software and also how to verify it.  Once you notice, we have to download it from this location.  Then when the download is complete, we have to basically check the signatures  and if the integrity is intact, we can extract it.  And then we have new content and we can look again if there's something missing.  So this is like going in iterations.  And now for each of the steps, we can look how to accomplish this.  You see that in the center of the whole thing, there's this download manager.  So this is the component that orchestrates everything.  And this is really critical.  This must be protected by all means.  And this download manager does not do any dirty work.  It is even picky about touching files on the fly system.  It won't do that.  Instead, for example, to find out what's missing, it basically uses a companion G-node subsystem  and configures this one to spawn a kind of minion kind of component that does the dirty work for this guy.  So the download manager just tells this one, please find out what's missing.  And so this guy starts walking around looking at this part of the fly system  and finds out, ah, I need this and this new content, this is missing.  And reports this back to the download manager using this report interface.  And next step, the report query component is basically then commissioned to work to find out where to get this software from.  And once this information is cleared, we know, OK, we want to have this content  and we can download it from this and this place.  And now let's download it.  And here things get really dangerous because now we have the network connectivity over here.  And we have now a whole software stack for downloading the content, yeah,  like the TCPIP stack ported from Linux, SSL, QL, and so on.  And so this is hugely complex.  That's a complex thing.  It's connected to the network, so we assume it's compromised.  So an attacker can go from here inside there and it could also land in this kind of place of the fly system.  Yeah, so this is basically our assumption that this is already infected.  So the next step, we completely cut off the network connection  and replace this whole networking stack with another component, with this verify component.  And this one only has access to this part of the fly system.  And while doing the verification, no other component touches this area.  So there could be no network application writings to it.  But so we know that the result of the verification is basically integer.  So in the end, we have this decision, good or bad.  And we can basically then go on and extract it.  And here it's another consideration.  Let's say I download some software from a company I don't trust.  I still want to use this software, like for example Adobe Flash Player or something like that.  So I want to use the software, but I don't trust Adobe.  So if the signature is right, I'm still not happy because, yeah, I don't trust them.  So what I want to enforce is that everything that comes from Adobe gets placed in a dedicated area  on my hard disk that is labeled Adobe and I can wipe it off the hard disk at any time.  And this can be accomplished by just having this change root component here.  Basically it intercepts this fly system session here  and the extraction program can extract content only to this particular part of the fly system.  So that means that you can install with G-Node, with this root less,  you can install peerless applications from untrusted parties.  And we know that this is integer, but we can, of course, we check the signatures.  But we can just do this.  And once we deploy the applications, we still can decide what kind of resources to hand out to the application.  So for example, if for some reason the Flash player would like to access our config FS,  we can still just route the session to an empty RAM FS and then virtualize everything.  So, okay, now enough talk.  Maybe I can, I am happy to show that it really works.  Let's see if we have some component here.  It's not yet installed.  Let's, for example, click on this one.  So now the system will probably find out that there is no, it's not installed yet.  This program I have clicked on.  And now here you see that it now fetches the content from for this QT application.  And...  Yeah, yeah, don't worry.  But it's working.  No, we are at the point of slow micro-conveyor systems, right?  But I think it's not slow, really.  You can use it and it's practical for day-to-day work.  So, it's the code switch that you want to...  Would you want to tell something about Hedermas, right?  Yeah, I'd like to attend a minute.  Yeah, that's okay.  Okay.  No, maybe I...  Yeah, if you let me speak, then I will just go on.  That's right.  So, here we have this QT application.  So, you see here that now we have just installed and deployed this application.  And so, this is some basic blurs, the line between deploying and installing.  It's basically what's on the hard disk, the depot on the hard disk is basically just a cache.  We can wipe it off and we can click again on the item and it will install what's needed on demand.  Okay, that's the point where I would like to wrap up.  Thanks for the chance to present it here.  And if you'd like to look at it, you can find it on our geno.org site.  And, yeah, that's it.  Thanks.  Thank you.  Thanks.  Thanks.  And that looks more unmuted.  Okay, hello.  This is me again today.  I'm Jakub from Kern Concept.  But this time I am stepping in for a friend who was originally supposed to deliver this much longer talk about Hellenos  and the evolution of its file system layer.  Unfortunately, he fell ill.  So I would like to take this opportunity and only give a short Hellenos update in the remaining eight or so minutes.  So for those of you who don't know how Hellenos looks like and what it is, I can...  Maybe I can show you a short demo right from the beginning.  So I've just started off Hellenos.  That's interesting.  So this is Hellenos running on AMD64, but we also support some other architectures like Spark64,  Itanium, ARM32.  Today the micro-cranel in the room had a visitor who is no longer here, I guess,  Petr Pavlu, and who suddenly appeared from nowhere and wrote a message to our mailing list saying,  by the way, here is a port of Hellenos to 64-bit ARM and I've been working on it for four years.  So you can, of course, control Hellenos the usual way.  Just don't get confused or don't get mistaken.  This is not a Linux distribution even though some of the commands might give you that impression.  But everything that I'm running right now...  This is an OS.  Right, so this was the audio stack.  Everything I'm running by now was written by us or some students that we were supervising.  Hellenos is probably one of the very few micro-cranel projects that actually writes its device drivers  and file systems and networking stacks itself.  So to contrast this with L4RE that I spoke about previously, where the way would be to take some existing component,  maybe a whole VM which runs the networking stack or provides some device drivers,  we would write them ourselves.  And especially this is true for the gentleman who was supposed to deliver this talk in the first place.  So we can do also some fancier stuff in our group.  But I don't think we have that much time to play with that.  Just ping the local host.  We can't ping a local host.  We can ping a non-local host like on QMood.  It's a different number. It's like 10.  Or 15? Is it 15?  Never mind, this is supposed to work.  But in general you can ping something out of the...  something which is listening on the network interface,  but there is no kind of link to the local host.  You can't ping local host. That's like a small alliance.  So enough with the demo itself.  Let's just see what we have done since last was done.  So there was a release in July.  Hellenos07.2 was released.  Some of the highlights are a rewrite of the USB stack.  We had a group of students who wrote a new USB 3.0 stack  by adding the XHCI controller  and basically rewriting the stack from the most part.  We did some device drivers like Verti-onet.  Another student worked on adding C++14 support  for C++14.  Finally, did something about our Lipsy compliance  because when we started many years ago,  we were... I think Norman describes that as a cowboy attitude.  We were like, yeah, we can do everything.  We won't be compatible with anything.  So that changed a little bit.  So nowadays we tend to draw the line at the C,  standard C library, and try to be compatible on that level  and throw all the other legacy away.  I did some capability work  for which I would refer you to my talk from last was done.  Irka, the original presenter of this,  he worked on automatic volume mounting.  So whenever Hellenos spots file system  which has a volume, it automounts it.  That's kind of like when you have a flash disk  and plug it into your Linux or Windows computer,  it automatically gets mounted.  So this is something like that.  Then in another release which happened in December,  we switched to our custom GCC target  which already managed to slightly backfire.  But other than that, it's a pretty good idea  because now we have the whole thing  that builds Hellenos under our control  and there are no surprises  in terms of what the compiler can do  if we squat on the Linux target  that we were using previously.  We had some improvements in the kernel.  Basically there is a new red-black tree-based data  structure which replaced the existing Avia and B-plus trees.  It was heavily used in memory management.  The new data structure has just slightly better API  which is more favorable to memory management  because it does not allocate anything on its own.  You have to pass it memory.  Then we threw out a couple of things  like the complete RCU  and concurrent hash table implementation  because we are not using it actively  and there were some bugs  and the thing was not maintained  and in the spirit of this new phenomenon,  was it Marie Condé?  His name.  It didn't spark joy so we completely removed RCU and CHD.  Then the work on the volume manager  and the volume layer continued.  The system is trying to preserve slash W  as something which is always mounted  with the file system on which HLENOS was installed.  Then there were some fixes.  Also the capability work continued.  Some new packages.  Now you can install a package  which is a ZX Spectrum emulator  and there is another one which is not a package yet  but rather a branch of HLENOS on GitHub  which is a NES emulator.  If you happen to own some of the ROMs,  you can even play some retro games on HLENOS right now.  As for what new features were added to HLENOS after the release,  unlike before when we only supported dynamic linking on IA32,  Irka, the guy who should have been here,  he also added the NB64 ARM32 power PC and Spark 64 dynamic linking  and I believe that he is working on the remaining architectures  right now.  I show you the PCI utility at the beginning  so that's just a utility which allows you to see  what PCI devices were discovered by the device driver framework  and I already told you about the pending ARM64 port of HLENOS.  As for the plans,  finish dynamic linking support.  Martin is working on risk 5 support  that would nicely complement our collection of supported architectures.  Of course there is still a lot of work to be done on the capability front.  As for this file system management,  I think that translates to changes that are related to this file system work  and volume management to make the system more user friendly.  That's one of Irka's goals.  And also in the same vein and the same category,  dynamic and persistent and work configuration,  I'm also suspecting he wants to rewrite the graphical user interface  that I showed you at the beginning.  We revived our doxigen documentation which was non-existent for a long time  and probably the last thing,  yes, the last thing I would like to mention is  there is going to be a new virtual block driver  because we realized that by having one  we would actually allow some more exotic architectures like Spark64  and PowerPC and probably also some ARM ones  to have an actual block driver which they don't have right now  and we are constantly struggling with making the boot image small  so that it fits and can be booted from.  And having a block device driver is one of the things  that we need to switch to a fully supported scheme like we have on X86  where we can boot from an installed system.  So, virtual block driver is coming and thank you for your attention.  applause  applause  applause  applause  applause  applause  applause  applause
Microkernel_lightning_talks_5duoNZR5TJs_0_179.png Microkernel_lightning_talks_5duoNZR5TJs_180_323.png Microkernel_lightning_talks_5duoNZR5TJs_324_455.png Microkernel_lightning_talks_5duoNZR5TJs_456_1415.png Microkernel_lightning_talks_5duoNZR5TJs_1416_2423.png Microkernel_lightning_talks_5duoNZR5TJs_2424_4091.png Microkernel_lightning_talks_5duoNZR5TJs_4092_4139.png Microkernel_lightning_talks_5duoNZR5TJs_4140_4187.png Microkernel_lightning_talks_5duoNZR5TJs_4188_7559.png Microkernel_lightning_talks_5duoNZR5TJs_7560_8303.png Microkernel_lightning_talks_5duoNZR5TJs_8304_8411.png Microkernel_lightning_talks_5duoNZR5TJs_8412_9707.png Microkernel_lightning_talks_5duoNZR5TJs_9708_9803.png Microkernel_lightning_talks_5duoNZR5TJs_9804_15971.png Microkernel_lightning_talks_5duoNZR5TJs_15972_16259.png Microkernel_lightning_talks_5duoNZR5TJs_16260_18191.png Microkernel_lightning_talks_5duoNZR5TJs_18192_18311.png Microkernel_lightning_talks_5duoNZR5TJs_18312_20303.png Microkernel_lightning_talks_5duoNZR5TJs_20304_20363.png Microkernel_lightning_talks_5duoNZR5TJs_20364_20411.png Microkernel_lightning_talks_5duoNZR5TJs_20412_31643.png Microkernel_lightning_talks_5duoNZR5TJs_31644_32759.png Microkernel_lightning_talks_5duoNZR5TJs_32760_33635.png Microkernel_lightning_talks_5duoNZR5TJs_33636_34343.png Microkernel_lightning_talks_5duoNZR5TJs_34344_34427.png Microkernel_lightning_talks_5duoNZR5TJs_34428_34475.png Microkernel_lightning_talks_5duoNZR5TJs_34476_36095.png Microkernel_lightning_talks_5duoNZR5TJs_36096_36167.png Microkernel_lightning_talks_5duoNZR5TJs_36168_36227.png Microkernel_lightning_talks_5duoNZR5TJs_36228_36275.png Microkernel_lightning_talks_5duoNZR5TJs_36276_36371.png Microkernel_lightning_talks_5duoNZR5TJs_36372_36443.png Microkernel_lightning_talks_5duoNZR5TJs_36444_39119.png Microkernel_lightning_talks_5duoNZR5TJs_39120_39167.png Microkernel_lightning_talks_5duoNZR5TJs_39168_40619.png Microkernel_lightning_talks_5duoNZR5TJs_40620_42767.png Microkernel_lightning_talks_5duoNZR5TJs_42768_49451.png Microkernel_lightning_talks_5duoNZR5TJs_49452_51911.png Microkernel_lightning_talks_5duoNZR5TJs_51912_52883.png Microkernel_lightning_talks_5duoNZR5TJs_52884_54263.png Microkernel_lightning_talks_5duoNZR5TJs_54264_54515.png Microkernel_lightning_talks_5duoNZR5TJs_54516_54863.png Microkernel_lightning_talks_5duoNZR5TJs_54864_54983.png Microkernel_lightning_talks_5duoNZR5TJs_54984_55307.png Microkernel_lightning_talks_5duoNZR5TJs_55308_55379.png Microkernel_lightning_talks_5duoNZR5TJs_55380_55427.png Microkernel_lightning_talks_5duoNZR5TJs_55428_56363.png Microkernel_lightning_talks_5duoNZR5TJs_56364_57119.png Microkernel_lightning_talks_5duoNZR5TJs_57120_57241.png