The VFS paradigm from the perspective of a component OS
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.
Helmuth, Christian
The virtual file system (switch) is an instrinsic element of traditionaloperating systems and the majority of alternative OSes alike. For the mostpart, this is caused by existing applications that depend on the fileabstraction and to some extent on a global view on system resources. Incontrast, component-based OSes with strong security ambitions strive to applythe principle of least authority and shun one global view on the system. Thiswas the starting for the VFS developments for Genode. The talk will presentour design considerations and the current state of the VFS in Genode as acomponent and capability-based microkernel operating system.
 Okay, I want to talk today about how we approach the topic of the virtual file system in genode. So it's not an academic talk, it's just an experience report, what we did and what we did, what was up with our experiences. So, and the talk has four parts. I first want to give a motivation. Why did we took at this topic? Why have you had to look at the virtual file system? Because it's not so natural to take this task in a micro-conner system that is structured like genode. So, and the second part I will give the first steps we did and how the system evolved and in the third part I will describe our current state of the implementation and what we can do with the virtual file system in the end I will give an outlook and present some ideas how to go on. So, and starting point for us with our geno system was if we implement an operating system it does not make any sense, it's not of much use if you don't have applications on top of it. We want to use our known applications from the system we came from, it was mostly Linux and we also want to have our beloved tools in the shell and interact with the system in a normal way. So, how could we come to this state that we have the applications on top of the operating system? So, and the key element is to use open source applications so we can just look at the code, tweak it in some places and port it on top of the geno system. And later on we could also have a more detailed look into the components, analyze them and do some security-oriented decomposition of the system, of the applications and analyze some sensitive parts out of complex big applications that should hold our security properties. But the big but is that it's not very appealing to look at really complex components. So, one complex component many people are using is the Thunderbird Mail client and it's really complex in its source code and it's also using very complex libraries and who wants to look at this source code and try to decompose it, you just want to use it as it is and then try to build a secure system around it and make it better in that way. So, the observation was that these traditional applications that don't get really ported to geno, get decomposed into smaller components, these traditional applications will prevail, they will always be around. So, and now we have this situation that we have the geno system which has a system structure that is very different from the original POSIX environment. So, what does it mean that the application runs in the POSIX environment? What are the requirements? So, we had to look at it and analyze that one first big property of the system that must always be there is that the application has a fairly global view on the resources of the system. You'll always expect that there is a global tree of directories and fires where the resources of the system can be accessed and those resources are also very different in nature. It's not only the data on the storage files we know of like pictures or emails, it's also configuration data that is in fires and to some extent also hardware peripherals are accessed via fires. And even the graphic user interface is based on a file-based access to its resources. And additional points where that all those applications know of the POSIX world in sense of there is only traditional access control, not that they are administrative tools that change access to resources but also that they try to be robust if the user does something that's not expected like assessing a file with writing to a file that has only permissions. And also these applications need the C or C++ runtime. The C library is the basic layer that's below almost all applications in the POSIX system. And what we also saw at this time was that the POSIX IBI is really huge. So it cannot be grasped easily in its entireness and on the other hand the applications are only using a small share. So we had someone somehow to identify what is used by the applications from the system API so that they can be ported on top of the genome system. So the genome system on the other hand is very different and it comes down to three points. It's microkernel based. It's very different from a monolithic system so the microkernel does not provide any abstractions that are not needed. So we have no FI system in the kernel. The genome system is also capability based which means mostly that we don't have a global namespace. As I said before for the POSIX applications they depend on the global view on the resources that are used. We don't have that in the genome system. We don't want that in the genome system because of the security considerations you have to take if you introduce a global view on the resources. In the capability based system like genotes we also have fine grained access control. We have object capabilities that can be delegated to components in a very fine grained way. We not only have fires with permissions, it's more like an evolving system if the access permissions are delegated to the system. The third point is that genote is a component based system. With genote we want to keep up this notion of components. Components should not be too complex. It should be software applications or services that can be analyzed if they hold up their security properties and if they do their job like they expected to do. All of these components in the genome system can be combined how the use case needs it. So the router implementation needs very different system structure than a PC like I'm using here for the talk. We want to provide a system where the system integrator can put the bricks of the system and plug them together and have a system that only does what is needed for the use case. In the end it's always the system that the software complexity that introduces bugs and also security holes into the system. We think it's important to keep the software complexity as low as possible. Then comparing those two systems, the original POSIC environment and also the genome system, it sounds like a viable approach to just take the POSIC application and put it in a sandbox. The coarse grained kind of sandbox could be a virtual machine or a paravirtualized system, but there are also other means like we just took the approach to customize the C library. We take the application on top of the genome system and try to recompile it with a customized C library. That's not everything that does not fulfill any requirement application has. We also need some more elements of a runtime environment and one element is the virtual file system. The application can access resources like it's used to. That is also the point. The application now runs in a component, in a micro-corner system, and there is the traditional functions like read, write, and open, and a simple file system implementation, and this must somehow be connected to the outside world, to the genome system. So we have to find a way to connect the libc backend to genome services. That's the point we started. We implemented a backend for a subset of the libc functions, and naturally the subset of the first applications we wanted to port. These were only a dozen or two dozen functions. Then we added some small tweaks or hacks to emulate some mechanisms that were expected by the applications, in a run-over state, and we could make our practical experiences. Starting from this state, we could extend the C library by the mentioned connection to the genome services. To achieve that, we introduced a kind of plug-in structure into the C library, so that the C library could be extended on start time by shared libraries that implement plug-ins that adapt the C library to genome services. Here's a list of the first plug-ins we implemented. We ported some simple file system implementations into libraries on top of genodes, linked them to the application, and only connected the block accesses to the block services of the system. So the application could use exclusively a partition of the hard disk, maybe. We also ported network stacks like the lightweight IP stack, or also a version of the Linux IP stack on top of genodes that was co-located to the application as a library, and connected just to the network interface. We also did some experiments with graphics depicted at the bottom here. The libc plug-in interface had much in this case, so we could just link together more complicated stuff like the ported version of the Gallium graphics stack on the libdm interface and connect to a graphics driver on top of genodes. This is a picture of how it looked like at that time. We have an application at the very top that is almost not changed to run on genodes, because it's only using the freebsd port of the libc library, and then we plug in our plug-ins in this case for access to files on a FAT file system. That's the whole component the application is running in. Then we have a microkernel or genode primitives session to a block service that connects the application to the block device driver in this case. Now it's also possible to implement the files in the component on top of the microkernel. That sounds like a more natural way, so in this case we need another plug-in for the same application that does not connect to the block service, but to the file system service, which in turn then uses the block device driver at the bottom. That depicts one of our goals. The integrator of the system can choose how to structure its system, how the application should be connected to the services, and how big the component should be. Then we had some first applications running on top of genodes, like the NetPurve server to test network implementation or some small other components. But what we are missing, we are all beloved tools, our traditional working environment with the shell and the Unix tools and all that stuff. So we started a new development, so-named NUX runtime for Unix software, that should enable to also start these simple command line oriented tools on top of genodes. And the nature of those components is that they are spawned by a shell and that they are connected by pipes and run in loops and all that stuff. And what our Lipsy was missing at this time was that processes could start other processes. We did not implement the POSIX feature in the Lipsy because of some hard to achieve properties. So we took a different approach, we implemented a simple runtime component for those applications. And the good thing about that is that we could also take those tools in their source code archive form, configure them with the normal configuration tools and build them with their own build system and just link them to our C library and start them on top of the Unix runtime environment. We did not have to adapt in this area. And what the difference is now that we don't have one application that has a view on the resources in the system by the connected genome services. We have a bunch of applications running on top of one runtime that's using a shared resource representation. And this is how it looks like. We still have on top the recompiled application that's using our Lipsy. And now we don't use the plug mechanism in the Lipsy to plug the direct wrapper to genome services like block file system or network. We connect this component to the NUX runtime component. And that's not shown in this picture. Each component of this session runs on the same NUX runtime. So the natural first component that started is a shell. Maybe just imagine that this the BASH program running on top of NUX and that can then instruct the NUX runtime via the session and fork an exit call to spawn its children and also connect them via IO channels. So what it's new in NUX is that we did not implement the VFS or file access in a talk way. It was more formalized like a VFS implementation, like a first VFS implementation. We had a library that implemented a framework for a directory tree where we could plug in several features of the VFS, like just mount and tar archive as a subtree of the system. Okay. Yeah. So after some experience with the NUX runtime environment and the feeling that that is a very big step forward, we thought, okay, now we have this VFS framework. We have several plugins inside the NUX runtime. But the problem now is that those bare libc components running on top of GNUD cannot profit from the VFC implementation. So we had to move also this implementation into the libc and then share these functionalities between both components. And we could also gradually replace those special libc plugins by VFS plugins. So we don't have two code bases to maintain. So we can come now back from the resource representation for the whole NUX runtime to the per process representation in the VFS instance. And we can now again individually configure how one application interacts with the system. And that's also the next part. I want to show you how the VFS is configured in GNUD. In GNUD, we are using XML to configure our components. It's very easy to parse. We have a very low complexity parser for it. And our components use the same configuration mechanism and share the same code for this. So it's natural to also configure the VFS by XML means. And as you can see here, the VFS is just one sub node of the component configuration. And the first thing that is needed in the VFS are directories. So you can add a directory node to the VFS and give it a name. And the other plugins are then just nodes inside the directory nodes or at the top level. So and the nodes, like with the directory node, also the other plugins have those are instantiated based on their name. And the VFS configuration must then be used by Lipsy. So we also have a configuration node for the Lipsy that maps Lipsy mechanisms or functions to the nodes in the VFS. In this case, the standard out and standard error should go to the VFS plugin. And this is how it would look like completely in one node. So what we gain here is that we have a precise declaration of resource representation in the VFS. So anybody can look at the configuration and see, OK, these resources are available to this component in the system. As I described for the TAR plugin, those plugins cannot only implement single files. But they can also implement whole subtrees, whole directory subtrees like a TAR archive or external file system. And with this in mind, we implemented the feature in the VFS that these nodes are organized as a stack of a file system at one level. So if you have a file system in, maybe you have a file system here in DIR or two file systems and a file is not found in the first one, you can, like in the union mount, look in the second one and do a look up there. And the last part is that the VFS configuration and the libc configuration are both two distinct things. And you can just tweak the behavior of the libc library with its own configuration node. So we have a bunch of plugins in our VFS implementation. The first one we used is a mapping to our ROM source as a microkernel system that we needed some means to use boot modules in the system and we named them ROM and we can also map nodes in the file system in the VFS to ROM nodes. So like with a directory, a ROM can be given a name in the VFS that must not be the name of the actual boot module. The result that is looked up in the system is more like, is given here in an extra attribute. So you can also establish nodes in a system that have another name when looking up the service that implements the session. Mostly for debugging but also for static configuration of systems we included an inlight node where it's possible to just create a file in the VFS that has a fixed content. And also we needed some handy tools for the POSIX applications like the classical def null and zero devices and also we have a simple sim link implementation where you can have a node in the VFS that redirects to another node. And the first important file system we implemented was a local instance of a kind of tempFS, a ROM file system. So these applications could generate temporary files and store data in them. I also talked about the Tor node. And then we also have these mentioned files to service wrappers that provide genome services directly in one file. So we can enable the C applications to get some real time or use terminals for maybe standard in standard out and also access block devices directly. Like we did with the libc in our early developments we also implemented a runtime extension feature of the VFS. So it's possible to name nodes in the VFS that are not known to the core implementation and in this case the implementation tries to open shared object files that are linked at runtime to the application and used as custom VFS plugins. And we also have some examples in our directivity. The first example is a random generator implementation based on the Chidro entropy of the CPUs that can be used in applications like networks applications or we also use it in our Wi-Fi implementation. And the second example is a one-time, a time-based password generator that can just be linked as a file into the VFS. Also important is to connect existing file system services to the application so several libc-based applications can also share one partition of the system and access it. And the first attribute is always here depicted the name of the mount. So the file system here, we have here three file system mounts with three distinct names. And what I use here is also the label attribute to say, okay, the file system node that's in config should redirect to the resource as labeled config. And we could also provide local configuration of plugins in those nodes. In the case of the file system, we can allow or disallow to write to files in the file system. We can also say, okay, when the file system session is requested from the service just provide a root configuration attribute as we only want to use a subdirectory of the mount of the file system. But the important thing to note here is that these configurations are only process local. These are only for the application that's running on G-node. And the service itself is configured by other means. It uses policies that are provided in the configuration node of the service itself. And those look somewhat familiar if one knows the configuration nodes of the file system, of the VFS. But here the actual properties are enforced, like this session that uses this file system is able to write or not to write to the file system. And also the visibility can be limited and enforced in the session. So that is almost the state we are now. There's only one component missing and that's the VFS session. So that is somewhat strange. I talked about we want to split in multiple components. We don't want central namespace. Okay. So should I just stop or? Yeah, okay. Just keep talking. Yeah, what we now have is a VFS server. We don't want the global namespace. We want to use the VFS server as a tool that can also be multi-incentivated in the system model. And it's just a tool to use these VFS configurations and share them among several components. That does not mean all components are using the same VFS server. So, uh-huh. Yeah. Yeah, I don't know. Sorry. So are there any questions? Can you use a modifier configuration for its own tuning of the environment he's working in? That depends on the system configuration. So, in Gino, these configuration files used by applications, by components, by all components, are just ROM files. Who may change these ROM files at runtime depends on the system policy. So, if I implement a service in the system, that the user can change several aspects of this configuration, this trusted service could then update the configuration of the components. What is the service date related to the, let's say, the most complex application that you've announced? Um, I think the most complex application, policy application we are hosting is virtual box. But it's not fair to name it on this question because that's a very special case. Um, yeah, we also have cute applications running on top of Gino. Web, simple web servers. Yeah, it all depends on the share of the post interface that it's used. In some cases, you very early on ran into not implemented functions, and in some cases, it just works out. Okay, thank you. Thank you.
 Okay, I want to talk today about how we approach the topic of the virtual file system in genode.  So it's not an academic talk, it's just an experience report, what we did and what we  did, what was up with our experiences. So, and the talk has four parts. I first want to give a motivation.  Why did we took at this topic? Why have you had to look at the virtual file system? Because it's not so  natural to take this task in a micro-conner system that is structured like genode. So, and the second  part I will give the first steps we did and how the system evolved and in the third part I will  describe our current state of the implementation and what we can do with the virtual file system in  the end I will give an outlook and present some ideas how to go on. So, and starting point for us  with our geno system was if we implement an operating system it does not make any sense, it's not  of much use if you don't have applications on top of it. We want to use our known applications from  the system we came from, it was mostly Linux and we also want to have our beloved tools in the shell  and interact with the system in a normal way. So, how could we come to this state that we have the  applications on top of the operating system? So, and the key element is to use open source  applications so we can just look at the code, tweak it in some places and port it on top of the  geno system. And later on we could also have a more detailed look into the components, analyze them  and do some security-oriented decomposition of the system, of the applications and  analyze some sensitive parts out of complex big applications that should hold our security properties.  But the big but is that it's not very appealing to look at really complex components. So, one complex  component many people are using is the Thunderbird Mail client and it's really complex in its source code  and it's also using very complex libraries and who wants to look at this source code and try to  decompose it, you just want to use it as it is and then try to build a secure system around it and  make it better in that way. So, the observation was that these traditional applications that don't  get really ported to geno, get decomposed into smaller components, these traditional applications  will prevail, they will always be around. So, and now we have this situation that we have the  geno system which has a system structure that is very different from the original POSIX environment.  So, what does it mean that the application runs in the POSIX environment? What are the requirements?  So, we had to look at it and analyze that one first big property of the system that must always be there  is that the application has a fairly global view on the resources of the system.  You'll always expect that there is a global tree of directories and fires where the resources of the  system can be accessed and those resources are also very different in nature. It's not only the data on  the storage files we know of like pictures or emails, it's also configuration data that is in  fires and to some extent also hardware peripherals are accessed via fires. And even the graphic user  interface is based on a file-based access to its resources. And additional points where that all those  applications know of the POSIX world in sense of there is only traditional access control, not that  they are administrative tools that change access to resources but also that they try to be robust if  the user does something that's not expected like assessing a file with writing to a file that has only  permissions. And also these applications need the C or C++ runtime. The C library is the basic layer  that's below almost all applications in the POSIX system. And what we also saw at this time was that  the POSIX IBI is really huge. So it cannot be grasped easily in its entireness and on the other  hand the applications are only using a small share. So we had someone somehow to identify what is used  by the applications from the system API so that they can be ported on top of the genome system. So the  genome system on the other hand is very different and it comes down to three points. It's microkernel  based. It's very different from a monolithic system so the microkernel does not provide any abstractions  that are not needed. So we have no FI system in the kernel. The genome system is also capability  based which means mostly that we don't have a global namespace. As I said before for the POSIX  applications they depend on the global view on the resources that are used. We don't have that in the  genome system. We don't want that in the genome system because of the security considerations  you have to take if you introduce a global view on the resources. In the capability based system like  genotes we also have fine grained access control. We have object capabilities that can be delegated to  components in a very fine grained way. We not only have fires with permissions, it's more like an  evolving system if the access permissions are delegated to the system. The third point is that  genote is a component based system. With genote we want to keep up this notion of components.  Components should not be too complex. It should be software applications or services that can be  analyzed if they hold up their security properties and if they do their job like they expected to do.  All of these components in the genome system can be combined how the use case needs it. So  the router implementation needs very different system structure than a PC like I'm using here for the talk.  We want to provide a system where the system integrator can put the bricks of the system and plug them  together and have a system that only does what is needed for the use case. In the end it's always the  system that the software complexity that introduces bugs and also security holes into the system.  We think it's important to keep the software complexity as low as possible.  Then comparing those two systems, the original POSIC environment and also the genome system,  it sounds like a viable approach to just take the POSIC application and put it in a sandbox.  The coarse grained kind of sandbox could be a virtual machine or a paravirtualized system,  but there are also other means like we just took the approach to customize the C library.  We take the application on top of the genome system and try to recompile it with a customized C library.  That's not everything that does not fulfill any requirement application has.  We also need some more elements of a runtime environment and one element is the virtual file system.  The application can access resources like it's used to.  That is also the point. The application now runs in a component, in a micro-corner system,  and there is the traditional functions like read, write, and open, and a simple file system implementation,  and this must somehow be connected to the outside world, to the genome system.  So we have to find a way to connect the libc backend to genome services.  That's the point we started.  We implemented a backend for a subset of the libc functions,  and naturally the subset of the first applications we wanted to port.  These were only a dozen or two dozen functions.  Then we added some small tweaks or hacks to emulate some mechanisms that were expected by the applications,  in a run-over state, and we could make our practical experiences.  Starting from this state, we could extend the C library by the mentioned connection to the genome services.  To achieve that, we introduced a kind of plug-in structure into the C library,  so that the C library could be extended on start time by shared libraries that implement plug-ins that adapt the C library to genome services.  Here's a list of the first plug-ins we implemented.  We ported some simple file system implementations into libraries on top of genodes, linked them to the application,  and only connected the block accesses to the block services of the system.  So the application could use exclusively a partition of the hard disk, maybe.  We also ported network stacks like the lightweight IP stack,  or also a version of the Linux IP stack on top of genodes that was co-located to the application as a library,  and connected just to the network interface.  We also did some experiments with graphics depicted at the bottom here.  The libc plug-in interface had much in this case, so we could just link together more complicated stuff like  the ported version of the Gallium graphics stack on the libdm interface and connect to a graphics driver on top of genodes.  This is a picture of how it looked like at that time.  We have an application at the very top that is almost not changed to run on genodes,  because it's only using the freebsd port of the libc library,  and then we plug in our plug-ins in this case for access to files on a FAT file system.  That's the whole component the application is running in.  Then we have a microkernel or genode primitives session to a block service  that connects the application to the block device driver in this case.  Now it's also possible to implement the files in the component on top of the microkernel.  That sounds like a more natural way, so in this case we need another plug-in for the same application  that does not connect to the block service, but to the file system service,  which in turn then uses the block device driver at the bottom.  That depicts one of our goals.  The integrator of the system can choose how to structure its system,  how the application should be connected to the services,  and how big the component should be.  Then we had some first applications running on top of genodes,  like the NetPurve server to test network implementation or some small other components.  But what we are missing, we are all beloved tools,  our traditional working environment with the shell and the Unix tools and all that stuff.  So we started a new development, so-named NUX runtime for Unix software,  that should enable to also start these simple command line oriented tools on top of genodes.  And the nature of those components is that they are spawned by a shell  and that they are connected by pipes and run in loops and all that stuff.  And what our Lipsy was missing at this time was that processes could start other processes.  We did not implement the POSIX feature in the Lipsy  because of some hard to achieve properties.  So we took a different approach, we implemented a simple runtime component for those applications.  And the good thing about that is that we could also take those tools  in their source code archive form, configure them with the normal configuration tools  and build them with their own build system  and just link them to our C library and start them on top of the Unix runtime environment.  We did not have to adapt in this area.  And what the difference is now that we don't have one application  that has a view on the resources in the system by the connected genome services.  We have a bunch of applications running on top of one runtime  that's using a shared resource representation.  And this is how it looks like.  We still have on top the recompiled application that's using our Lipsy.  And now we don't use the plug mechanism in the Lipsy to plug the direct wrapper  to genome services like block file system or network.  We connect this component to the NUX runtime component.  And that's not shown in this picture.  Each component of this session runs on the same NUX runtime.  So the natural first component that started is a shell.  Maybe just imagine that this the BASH program running on top of NUX  and that can then instruct the NUX runtime via the session  and fork an exit call to spawn its children  and also connect them via IO channels.  So what it's new in NUX is that we did not implement the VFS or file access  in a talk way.  It was more formalized like a VFS implementation,  like a first VFS implementation.  We had a library that implemented a framework for a directory tree  where we could plug in several features of the VFS,  like just mount and tar archive as a subtree of the system.  Okay.  Yeah.  So after some experience with the NUX runtime environment  and the feeling that that is a very big step forward,  we thought, okay, now we have this VFS framework.  We have several plugins inside the NUX runtime.  But the problem now is that those bare libc components running on top of GNUD  cannot profit from the VFC implementation.  So we had to move also this implementation into the libc  and then share these functionalities between both components.  And we could also gradually replace those special libc plugins  by VFS plugins.  So we don't have two code bases to maintain.  So we can come now back from the resource representation  for the whole NUX runtime to the per process representation  in the VFS instance.  And we can now again individually configure how one application  interacts with the system.  And that's also the next part.  I want to show you how the VFS is configured in GNUD.  In GNUD, we are using XML to configure our components.  It's very easy to parse.  We have a very low complexity parser for it.  And our components use the same configuration mechanism  and share the same code for this.  So it's natural to also configure the VFS by XML means.  And as you can see here, the VFS is just one sub node  of the component configuration.  And the first thing that is needed in the VFS are directories.  So you can add a directory node to the VFS and give it a name.  And the other plugins are then just nodes inside the directory  nodes or at the top level.  So and the nodes, like with the directory node,  also the other plugins have those are instantiated based on their name.  And the VFS configuration must then be used by Lipsy.  So we also have a configuration node for the Lipsy  that maps Lipsy mechanisms or functions to the nodes in the VFS.  In this case, the standard out and standard error should go to the VFS plugin.  And this is how it would look like completely in one node.  So what we gain here is that we have a precise declaration  of resource representation in the VFS.  So anybody can look at the configuration and see,  OK, these resources are available to this component in the system.  As I described for the TAR plugin, those plugins cannot only implement single files.  But they can also implement whole subtrees,  whole directory subtrees like a TAR archive or external file system.  And with this in mind, we implemented the feature in the VFS  that these nodes are organized as a stack of a file system at one level.  So if you have a file system in, maybe you have a file system here in DIR  or two file systems and a file is not found in the first one,  you can, like in the union mount, look in the second one and do a look up there.  And the last part is that the VFS configuration and the libc configuration  are both two distinct things.  And you can just tweak the behavior of the libc library with its own configuration node.  So we have a bunch of plugins in our VFS implementation.  The first one we used is a mapping to our ROM source as a microkernel system  that we needed some means to use boot modules in the system  and we named them ROM and we can also map nodes in the file system in the VFS to ROM nodes.  So like with a directory, a ROM can be given a name in the VFS  that must not be the name of the actual boot module.  The result that is looked up in the system is more like,  is given here in an extra attribute.  So you can also establish nodes in a system that have another name  when looking up the service that implements the session.  Mostly for debugging but also for static configuration of systems  we included an inlight node where it's possible to just create a file in the VFS  that has a fixed content.  And also we needed some handy tools for the POSIX applications  like the classical def null and zero devices  and also we have a simple sim link implementation  where you can have a node in the VFS that redirects to another node.  And the first important file system we implemented was a local instance  of a kind of tempFS, a ROM file system.  So these applications could generate temporary files and store data in them.  I also talked about the Tor node.  And then we also have these mentioned files to service wrappers  that provide genome services directly in one file.  So we can enable the C applications to get some real time  or use terminals for maybe standard in standard out  and also access block devices directly.  Like we did with the libc in our early developments  we also implemented a runtime extension feature of the VFS.  So it's possible to name nodes in the VFS that are not known to the core implementation  and in this case the implementation tries to open shared object files  that are linked at runtime to the application  and used as custom VFS plugins.  And we also have some examples in our directivity.  The first example is a random generator implementation  based on the Chidro entropy of the CPUs  that can be used in applications like networks applications  or we also use it in our Wi-Fi implementation.  And the second example is a one-time, a time-based password generator  that can just be linked as a file into the VFS.  Also important is to connect existing file system services  to the application so several libc-based applications  can also share one partition of the system and access it.  And the first attribute is always here depicted the name of the mount.  So the file system here, we have here three file system mounts  with three distinct names.  And what I use here is also the label attribute to say,  okay, the file system node that's in config  should redirect to the resource as labeled config.  And we could also provide local configuration of plugins in those nodes.  In the case of the file system, we can allow or disallow to write to files in the file system.  We can also say, okay, when the file system session is requested from the service  just provide a root configuration attribute  as we only want to use a subdirectory of the mount of the file system.  But the important thing to note here is that these configurations are only process local.  These are only for the application that's running on G-node.  And the service itself is configured by other means.  It uses policies that are provided in the configuration node of the service itself.  And those look somewhat familiar if one knows the configuration nodes of the file system, of the VFS.  But here the actual properties are enforced, like this session that uses this file system  is able to write or not to write to the file system.  And also the visibility can be limited and enforced in the session.  So that is almost the state we are now.  There's only one component missing and that's the VFS session.  So that is somewhat strange.  I talked about we want to split in multiple components.  We don't want central namespace.  Okay.  So should I just stop or?  Yeah, okay. Just keep talking.  Yeah, what we now have is a VFS server.  We don't want the global namespace.  We want to use the VFS server as a tool that can also be multi-incentivated in the system model.  And it's just a tool to use these VFS configurations and share them among several components.  That does not mean all components are using the same VFS server.  So, uh-huh.  Yeah.  Yeah, I don't know.  Sorry.  So are there any questions?  Can you use a modifier configuration for its own tuning of the environment he's working in?  That depends on the system configuration.  So, in Gino, these configuration files used by applications, by components, by all components, are just ROM files.  Who may change these ROM files at runtime depends on the system policy.  So, if I implement a service in the system, that the user can change several aspects of this configuration,  this trusted service could then update the configuration of the components.  What is the service date related to the, let's say, the most complex application that you've announced?  Um, I think the most complex application, policy application we are hosting is virtual box.  But it's not fair to name it on this question because that's a very special case.  Um, yeah, we also have cute applications running on top of Gino.  Web, simple web servers.  Yeah, it all depends on the share of the post interface that it's used.  In some cases, you very early on ran into not implemented functions, and in some cases, it just works out.  Okay, thank you.  Thank you.
The_VFS_paradigm_from_the_perspective_of_a_component_OS_0_59.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_60_131.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_132_323.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_324_491.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_492_623.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_624_2651.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_2652_5123.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_5124_5735.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_5736_6407.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_6408_6599.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_6600_7091.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_7092_7451.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_7452_8147.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_8148_8987.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_8988_13163.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_13164_13403.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_13404_15623.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_15624_15707.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_15708_15899.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_15900_15947.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_15948_22223.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_22224_25895.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_25896_28607.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_28608_28679.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_28680_31391.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_31392_33839.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_33840_36215.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_36216_40331.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_40332_44183.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_44184_45719.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_45720_45947.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_45948_46427.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_46428_47531.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_47532_47615.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_47616_47699.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_47700_47771.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_47772_51095.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_51096_51143.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_51144_51191.png The_VFS_paradigm_from_the_perspective_of_a_component_OS_51192_51313.png