Using QFS

Implementing the QNX Filesystem for Safety (QFS) includes creating a filesystem image, and configuring and starting the QFS driver.

Like other QNX OS filesystems, the QFS supports a wide variety of hardware and system configurations. This chapter uses a minimal configuration for a fictional target to illustrate the implementation steps.

For general information about QNX OS systems and filesystems, see QNX SDP 8.0 documentation such as Building Embedded Systems and System Architecture.

Creating a filesystem image

Creating the QFS filesystem image can begin with a buildfile that specifies the filesystem objects such as files and directories on your host platform to include in the generated filesystem image. It also specifies properties and permissions for each object.

For example, the following example buildfile creates a minimal filesystem. The image output contains:

  • a directory named xbin
  • the files ls and cat, copied from the x86_64/bin/ directory on the host system and stored in the xbin directory (their object type is file by default)
  • a directory named configs
  • the file test.cfg: it's located in the configs directory, its permissions are set using a four-digit octal number, and its content is specified inline
[type=dir] xbin
xbin/ls=x86_64/bin/ls
xbin/cat=x86_64/bin/cat

[type=dir] configs
[type=file perms=0750] configs/test.cfg = {
contents...
}

Details about the buildfile attributes are provided in the mkqfs (for QFS) chapter.

In addition to the buildfile, you need a public/private key pair. The mkqfs reference in this guide provides the key pair requirements.

The mkqfs utility that creates the image has options for specifying the buildfile and cryptographic resources. The following example command builds a QFS image using the buildfile input.build, and includes configuration for the metadata hash tree that underlies the integrity protection mechanism.
mkqfs qtsafefs -B 16384 -H sha256 -S rsa-sha256 -K rsa_test_private_key.pem -o qtsafefs.img input.build
  • The 16384 byte block size used to construct the hash tree approximates the file sizes found in the filesystem, to help improve the overall performance when accessing files.
  • The metadata hash tree is generated using SHA-256.
  • The cryptographic signature algorithm (in this case, RSA-SHA256) to use to sign the QFS image, and the private key that the algorithm uses (rsa_test_private_key.pem) are specified.
After you create the image, you can verify it on your host machine using mkqfs, specifying the public key that is associated with the private key that was used to sign the image. For example: 
mkqfs qtsafefs -y -K rsa_test_public_key.pem qtsafefs.img
Host machines can also extract the contents of a QFS image using mkqfs. For example : 
mkqfs qtsafefs -x -K rsa_test_public_key.pem -o extract qtsafefs.img

Starting the QFS driver

The method you use to deploy the QFS image and cryptographic keys to your target system depends on your hardware and configuration. (In any environment, private keys should be stored at a read-only location, and never included with a deployed system.)

Continuing the earlier example, after deployment the QFS image is located on a disk partition and present on the system as the device /dev/hd0t186, and the key is stored at /proc/boot/pub.key.

The following command mounts the qtsafefs filesystem from the disk partition. The partition is trusted and the rollback protection version must be 12 or greater: 

qtsafefsd -o key=/proc/boot/pub.key,trusted,rollback=12 /dev/hd0t186 /myfs

The following command mounts the filesystem image stored as a file on another partition. Eight threads are available in the qtsafefsd driver to service clients, and qtsafefsd uses the cryptographic algorithms provided by the QNX cryptography library (qcrypto) plugin that is associated with the myfs tag (instead of the default tag): 

qtsafefsd -o key=/proc/boot/pub.key,threads=8,qcrypto=myfs /data/myfs.img /myfs

For details about qtsafefsd options, go to qtsafefsd.

Page updated: