VFS: working with a network and files

VFS: overview

The VFS component contains the implementations of file systems and the network stack. POSIX calls for working with file systems and the network are sent to the VFS component, which then calls the block device driver or network driver, respectively.

Multiple copies of the VFS component can be added to a solution to separate the data streams of different entities. Each VFS copy is built separately and can contain the entire VFS functionality or a specific part of it, for example:

• One or more file systems
• Network stack
• Network stack and network driver

The VFS component can be used either directly (through static linking) or via IPC (as a separate entity). Use of VFS functionality via IPC enables the solution developer to do the following:

• Use a solution security policy to control method calls that work with the network and file systems.
• Connect multiple client entities to one VFS entity.
• Connect one client entity to two VFS entities to separately work with the network and file systems.

Building a VFS entity

KasperskyOS Community Edition does not provide a ready-to-use image for an entity containing the VFS component. The solution developer can independently build one or more entities that each include the specific VFS functionality necessary for the solution.

Building a network VFS

To build a "network" VFS entity containing a network driver, the file containing the main() function must be linked to the vfs_server, vfs_net and dnet_implementation libraries:

Using a "network" VFS entity linked to a network driver

To use a network driver via IPC (as a separate entity), the dnet_client library must be used instead of the dnet_implementation library:

Using a "network" VFS entity and a network driver as a separate entity

Building a file VFS

To build a "file" VFS entity, the file containing the main() function must be linked to the vfs_server and vfs_fs libraries and to the libraries for implementing file systems:

In this example, the VFS entity is prepared to connect to the ramdisk driver entity.

A block device driver cannot be linked to VFS and is always used via IPC:

Using a "file" VFS entity and a driver as a separate entity

Env entity

The Env service entity allows running entities to pass arguments and environment variables. When started, each entity automatically sends a request to the Env entity and receives the necessary data.

By including the Env entity in the solution, you can mount file systems when VFS is started, connect one client entity to two VFS entities, and perform many other tasks.

To use the Env entity in your solution, the following is required:

1. Develop the code of the Env entity by using macros from env/env.h.

2. Build an image of the entity by linking it to the env_server library.

3. In the init description, indicate that the Env entity must be started and connected to the selected entities (Env acts a server in this case). The channel name is defined by the ENV_SERVICE_NAME macro declared in the env/env.h file.

4. Include the Env entity image in the solution image.

Env entity code

The code of the Env entity utilizes the following macros and functions declared in the env/env.h file:

• ENV_REGISTER_ARGS(name,argarr) – arguments from the argarr array will be passed to the entity named name.
• ENV_REGISTER_VARS(name,envarr) – environment variables from the envarr array will be passed to the "name" entity.
• ENV_REGISTER_PROGRAM_ENVIRONMENT(name,argarr,envarr) – arguments and environment variables will be passed to the entity named name.
• envServerRun() – initialize the server part of the entity so that it can respond to requests.

Example:

Init.yaml example for use of the Env entity

In the next example, the Client entity will be connected to the Env entity whose image is located in the env folder:

Connecting a client entity to one or two VFS entities

Calls of network- and file POSIX functions can be forwarded to two separate VFS components by connecting a client entity to two different VFS entities. If such data stream separation is not required (for example, if the client only works with the network), connecting the client entity to a single VFS entity is enough.

Connecting to one VFS entity

The name of the IPC channel between the client entity and the VFS entity must be defined by the _VFS_CONNECTION_ID macro declared in the vfs/defs.h file. In this case, "network" calls and "file" calls will be sent to this VFS entity.

Example:

Connecting to two VFS entities

Let's examine a client entity that is connected to two different VFS entities. We will name them "network" VFS and "file" VFS.

The _VFS_NETWORK_BACKEND environment variable is used so that "network" calls from the client entity are sent only to the "network" VFS:

• For the "network" VFS entity: _VFS_NETWORK_BACKEND=server:<name of the IPC channel to the "network" VFS>
• For the client entity: _VFS_NETWORK_BACKEND=client: <name of the IPC channel to the "network" VFS>

The analogous _VFS_FILESYSTEM_BACKEND environment variable is used to send "file" calls:

• For the "file" VFS entity: _VFS_FILESYSTEM_BACKEND=server:<name of the IPC channel to the "file" VFS>
• For the client entity: _VFS_FILESYSTEM_BACKEND=client: <name of the IPC channel to the "file" VFS>

As a result, the functions for working with the network and files will be sent to two different VFS entities.

In the next example, the Client entity is connected to two VFS entities – the "network" VfsFirst entity and the "file" VfsSecond entity:

Env entity code:

Mounting file systems when VFS starts

By default, the VFS component provides access to the following:

• RAMFS file system. RAMFS is mounted to the root directory by default.
• ROMFS object storage. The storage contains non-executable files (including configuration files) that are added to the solution image during the build. The ROMFS file system is not mounted by default. However, the storage can be accessed indirectly through the -f argument, for example.

If you need to mount other file systems, this can be done either by using the mount() call after the VFS starts or immediately when the VFS starts by passing the following arguments and environment variables to it:

• -l <entry in fstab format>

  The -l argument lets you mount the file system.

• -f <path to fstab file>

  The -f argument lets you pass the file containing entries in fstab format for mounting file systems. The ROMFS storage will be searched for the file. If the UMNAP_ROMFS variable is defined, the file system mounted using the ROOTFS variable will be searched for the file.

• UNMAP_ROMFS

  If the UNMAP_ROMFS variable is defined, the ROMFS storage will be deleted. This helps conserve memory and change behavior when using the -f argument.

• ROOTFS = <entry in fstab format>

  The ROOTFS variable lets you mount a file system to the root directory. In combination with the UNMAP_ROMFS variable and the -f argument, it lets you search for the fstab file in the mounted file system instead of in the ROMFS storage.

Example: