diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/kconfig.rst | 8 | ||||
| -rw-r--r-- | docs/system/arm/nuvoton.rst | 1 | ||||
| -rw-r--r-- | docs/system/riscv/virt.rst | 6 | ||||
| -rw-r--r-- | docs/tools/virtiofsd.rst | 32 |
4 files changed, 42 insertions, 5 deletions
diff --git a/docs/devel/kconfig.rst b/docs/devel/kconfig.rst index d6b55a6fe0..69674d008a 100644 --- a/docs/devel/kconfig.rst +++ b/docs/devel/kconfig.rst @@ -192,11 +192,15 @@ declares its dependencies in different ways: no directive and are not used in the Makefile either; they only appear as conditions for ``default y`` directives. - QEMU currently has two device groups, ``PCI_DEVICES`` and - ``TEST_DEVICES``. PCI devices usually have a ``default y if + QEMU currently has three device groups, ``PCI_DEVICES``, ``I2C_DEVICES``, + and ``TEST_DEVICES``. PCI devices usually have a ``default y if PCI_DEVICES`` directive rather than just ``default y``. This lets some boards (notably s390) easily support a subset of PCI devices, for example only VFIO (passthrough) and virtio-pci devices. + ``I2C_DEVICES`` is similar to ``PCI_DEVICES``. It contains i2c devices + that users might reasonably want to plug in to an i2c bus on any + board (and not ones which are very board-specific or that need + to be wired up in a way that can't be done on the command line). ``TEST_DEVICES`` instead is used for devices that are rarely used on production virtual machines, but provide useful hooks to test QEMU or KVM. diff --git a/docs/system/arm/nuvoton.rst b/docs/system/arm/nuvoton.rst index adf497e679..ef2792076a 100644 --- a/docs/system/arm/nuvoton.rst +++ b/docs/system/arm/nuvoton.rst @@ -21,6 +21,7 @@ Hyperscale applications. The following machines are based on this chip : - ``quanta-gbs-bmc`` Quanta GBS server BMC - ``quanta-gsj`` Quanta GSJ server BMC - ``kudo-bmc`` Fii USA Kudo server BMC +- ``mori-bmc`` Fii USA Mori server BMC There are also two more SoCs, NPCM710 and NPCM705, which are single-core variants of NPCM750 and NPCM730, respectively. These are currently not diff --git a/docs/system/riscv/virt.rst b/docs/system/riscv/virt.rst index fa016584bf..08ce3c4177 100644 --- a/docs/system/riscv/virt.rst +++ b/docs/system/riscv/virt.rst @@ -23,9 +23,9 @@ The ``virt`` machine supports the following devices: * 1 generic PCIe host bridge * The fw_cfg device that allows a guest to obtain data from QEMU -Note that the default CPU is a generic RV32GC/RV64GC. Optional extensions -can be enabled via command line parameters, e.g.: ``-cpu rv64,x-h=true`` -enables the hypervisor extension for RV64. +The hypervisor extension has been enabled for the default CPU, so virtual +machines with hypervisor extension can simply be used without explicitly +declaring. Hardware configuration information ---------------------------------- diff --git a/docs/tools/virtiofsd.rst b/docs/tools/virtiofsd.rst index 07ac0be551..0c0560203c 100644 --- a/docs/tools/virtiofsd.rst +++ b/docs/tools/virtiofsd.rst @@ -104,6 +104,13 @@ Options * posix_acl|no_posix_acl - Enable/disable posix acl support. Posix ACLs are disabled by default. + * security_label|no_security_label - + Enable/disable security label support. Security labels are disabled by + default. This will allow client to send a MAC label of file during + file creation. Typically this is expected to be SELinux security + label. Server will try to set that label on newly created file + atomically wherever possible. + .. option:: --socket-path=PATH Listen on vhost-user UNIX domain socket at PATH. @@ -348,6 +355,31 @@ client arguments or lists returned from the host. This stops the client seeing any 'security.' attributes on the server and stops it setting any. +SELinux support +--------------- +One can enable support for SELinux by running virtiofsd with option +"-o security_label". But this will try to save guest's security context +in xattr security.selinux on host and it might fail if host's SELinux +policy does not permit virtiofsd to do this operation. + +Hence, it is preferred to remap guest's "security.selinux" xattr to say +"trusted.virtiofs.security.selinux" on host. + +"-o xattrmap=:map:security.selinux:trusted.virtiofs.:" + +This will make sure that guest and host's SELinux xattrs on same file +remain separate and not interfere with each other. And will allow both +host and guest to implement their own separate SELinux policies. + +Setting trusted xattr on host requires CAP_SYS_ADMIN. So one will need +add this capability to daemon. + +"-o modcaps=+sys_admin" + +Giving CAP_SYS_ADMIN increases the risk on system. Now virtiofsd is more +powerful and if gets compromised, it can do lot of damage to host system. +So keep this trade-off in my mind while making a decision. + Examples -------- |