VNCONFIG(8) BSD System Manager's Manual VNCONFIG(8)
vnconfig - configure vnode disks for file swapping or pseudo filesystems
vnconfig [-c] [-vkr] [-f keyfile] rawdev regular_file
vnconfig -u [-v] rawdev
vnconfig -l [rawdev]
vnconfig -K algorithm -f keyfile
The vnconfig command configures vnode pseudo disk devices. It will asso-
ciate (or disassociate) the special file rawdev with the regular file
regular_file allowing the latter to be accessed as though it were a disk.
Hence a regular file within the filesystem can be used for swapping or
can contain a filesystem that is mounted in the name space. Both tradi-
tional devices, vnd, and the cache-coherent devices, svnd, are configured
through vnconfig.
If you read the regular file while using svnd, you need to mount the svnd
with the mount option sync to ensure consistency in the buffer cache. For
normal operation this is not necessary.
The options are as follows:
-c Configures the device. If successful, references to rawdev will
access the contents of regular_file. This is the default opera-
tion.
-f keyfile
Instead of an encryption key read from stdin, an ASN.1 octet
string will be decoded from the PEM format keyfile. This option
implies -k.
-k Associate an encryption key with the device. All data will be en-
crypted using the Blowfish cipher before it is written to the
disk. Encryption only works with svnd, not with vnd.
-K algorithm
Generate a PEM format keyfile containing an encrypted ASN.1 octet
string which can be used as keyfile for further invocations of
vnconfig -kf. This is incompatible with the -K rounds / -S
saltfile method invented in OpenBSD 4.2.
If the -k option is also used, the system will convert an old
(plain password) encryption key to a keyfile by first asking
(twice) for the plaintext password, then (twice) for the PEM
passphrase with which to protect the keyfile (consisting of an
encoded version of the old plaintext password). This can be used
to migrate old encrypted volumes using the OpenBSD blowfish (bf-
cbc) format to the new keyfile-based scheme, which supports
changing the user (PEM) passphrase without needing to re-encrypt
the actual data.
If the -k option is not used, vnconfig will create a keyfile con-
sisting of 448 random bits (for use with the new-style bf-cbc al-
gorithm - other algorithms will follow and use different for-
mats), ask (twice) for a PEM passphrase with which the newly
created keyfile is to be protected, which can be changed by the
user without needing to re-encrypt the actual data, then save the
keyfile just created to disc.
The algorithm can be chosen from the default openssltool(1) list;
see below for an example.
-l List the vnd devices and indicate which ones are in use. If a
specific rawdev is given, then only that one will be described.
-r If the kernel supports it, don't write to the underlying file.
This is supported since MirBSD #7.
-u Unconfigures the device.
-v Print messages to stdout describing actions taken.
If no action option is given, -c is assumed.
/dev/{,r}{,s}vnd*
Configure the vnode disk svnd0 (all of its partitions become usable):
# vnconfig svnd0 /tmp/diskimage
Unconfigure the same device:
# vnconfig -u svnd0
Show a list of supported Cipher Types:
$ openssl enc -
Create an encrypted image and a keyfile:
$ dd if=/dev/arandom of=/tmp/foo.ima bs=1048576 count=16
$ vnconfig -K AES-256-CBC -f /tmp/foo.skf
Use an encrypted image with a keyfile:
# vnconfig -f /tmp/foo.skf svnd0 /tmp/foo.ima
openssl(1), openssltool(1), arc4random(3), blowfish(3), vnd(4), mount(8),
swapon(8), umount(8)
Support for external keyfiles was added in MirBSD #9.
This command should really be named vndconfig.
Currently, only bf-cbc (Blowfish) encryption in an OpenBSD compatible
format is available. Support for AES (including VIA C3 hardware accelera-
tion) is planned.
Configuring a block device, such as /dev/wd0e, as regular_file will
result in very bad I/O performance due to the use of synchronous (reli-
able) writes, even if the inner filesystem is mounted async or with sof-
tupdates. Character special devices cannot be used at all. This is a bug
inherited from OpenBSD.
MirBSD #10-current August 7, 2017 1