[v3,3/5] doc: give specific instructions for running as non-root
Checks
Commit Message
The guide to run DPDK applications as non-root in Linux
did not provide specific instructions to configure the required access
and did not explain why each bit is needed.
The latter is important because running as non-root
is one of the ways to tighten security and grant minimal permissions.
Cc: stable@dpdk.org
Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
---
doc/guides/linux_gsg/enable_func.rst | 89 +++++++++++++------
.../prog_guide/env_abstraction_layer.rst | 2 +
2 files changed, 64 insertions(+), 27 deletions(-)
Comments
On Fri, Jun 24, 2022 at 11:48:15AM +0300, Dmitry Kozlyuk wrote:
> The guide to run DPDK applications as non-root in Linux
> did not provide specific instructions to configure the required access
> and did not explain why each bit is needed.
> The latter is important because running as non-root
> is one of the ways to tighten security and grant minimal permissions.
>
> Cc: stable@dpdk.org
>
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Good improvements. One small suggestion below, otherwise:
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/linux_gsg/enable_func.rst | 89 +++++++++++++------
> .../prog_guide/env_abstraction_layer.rst | 2 +
> 2 files changed, 64 insertions(+), 27 deletions(-)
>
> diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
> index 1df3ab0255..0b57417c94 100644
> --- a/doc/guides/linux_gsg/enable_func.rst
> +++ b/doc/guides/linux_gsg/enable_func.rst
> @@ -13,13 +13,63 @@ Enabling Additional Functionality
> Running DPDK Applications Without Root Privileges
> -------------------------------------------------
>
> -In order to run DPDK as non-root, the following Linux filesystem objects'
> -permissions should be adjusted to ensure that the Linux account being used to
> -run the DPDK application has access to them:
> +The following sections describe generic requirements and configuration
> +for running DPDK applications as non-root.
> +There may be additional requirements documented for some drivers.
>
> -* All directories which serve as hugepage mount points, for example, ``/dev/hugepages``
> +Hugepages
> +~~~~~~~~~
>
> -* If the HPET is to be used, ``/dev/hpet``
> +Hugepages must be reserved as root before running the application as non-root,
> +for example::
> +
> + sudo dpdk-hugepages.py --reserve 1G
> +
> +If multi-process is not required, running with ``--in-memory``
> +bypasses the need to access hugepage mount point and files within it.
> +Otherwise, hugepage directory must be made accessible
> +for writing to the unprivileged user.
> +A good way for managing multiple applications using hugepages
> +is to mount the filesystem with group permissions
> +and add a supplementary group to each application or container.
> +
> +One option is to use the script provided by this project::
> +
> + export HUGEDIR=$HOME/huge-1G
> + mkdir -p $HUGEDIR
> + sudo dpdk-hugepages.py --mount --directory $HUGEDIR --owner `id -u`:`id -g`
> +
> +In production environment, the OS can manage mount points
> +(`systemd example <https://github.com/systemd/systemd/blob/main/units/dev-hugepages.mount>`_).
> +
> +The ``hugetlb`` filesystem has additional options to guarantee or limit
> +the amount of memory that is possible to allocate using the mount point.
> +Refer to the `documentation <https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt>`_.
> +
> +If the driver requires using physical addresses (PA),
> +the executable file must be granted additional capabilities:
> +
> +* ``SYS_ADMIN`` to read ``/proc/self/pagemaps``
> +* ``IPC_LOCK`` to lock hugepages in memory
> +
> +.. code-block:: console
> +
> + setcap cap_ipc_lock,cap_sys_admin+ep <executable>
> +
> +If physical addresses are not accessible,
> +the following message will appear during EAL initialization::
> +
> + EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Permission denied
> +
> +It is harmless in case PA are not needed.
> +
> +.. note::
> +
> + Using ``vfio-pci`` kernel driver, if applicable, can eliminate the need
> + for physical addresses and therefore reduce the permission requirements.
> +
Can we move this note up a bit, to immediately after the paragraph about
requiring physical addresses. It's better to inform the user immediately if
a section is not relevant to them, than only telling them at the end once
they have already read it.
/Bruce
@@ -13,13 +13,63 @@ Enabling Additional Functionality
Running DPDK Applications Without Root Privileges
-------------------------------------------------
-In order to run DPDK as non-root, the following Linux filesystem objects'
-permissions should be adjusted to ensure that the Linux account being used to
-run the DPDK application has access to them:
+The following sections describe generic requirements and configuration
+for running DPDK applications as non-root.
+There may be additional requirements documented for some drivers.
-* All directories which serve as hugepage mount points, for example, ``/dev/hugepages``
+Hugepages
+~~~~~~~~~
-* If the HPET is to be used, ``/dev/hpet``
+Hugepages must be reserved as root before running the application as non-root,
+for example::
+
+ sudo dpdk-hugepages.py --reserve 1G
+
+If multi-process is not required, running with ``--in-memory``
+bypasses the need to access hugepage mount point and files within it.
+Otherwise, hugepage directory must be made accessible
+for writing to the unprivileged user.
+A good way for managing multiple applications using hugepages
+is to mount the filesystem with group permissions
+and add a supplementary group to each application or container.
+
+One option is to use the script provided by this project::
+
+ export HUGEDIR=$HOME/huge-1G
+ mkdir -p $HUGEDIR
+ sudo dpdk-hugepages.py --mount --directory $HUGEDIR --owner `id -u`:`id -g`
+
+In production environment, the OS can manage mount points
+(`systemd example <https://github.com/systemd/systemd/blob/main/units/dev-hugepages.mount>`_).
+
+The ``hugetlb`` filesystem has additional options to guarantee or limit
+the amount of memory that is possible to allocate using the mount point.
+Refer to the `documentation <https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt>`_.
+
+If the driver requires using physical addresses (PA),
+the executable file must be granted additional capabilities:
+
+* ``SYS_ADMIN`` to read ``/proc/self/pagemaps``
+* ``IPC_LOCK`` to lock hugepages in memory
+
+.. code-block:: console
+
+ setcap cap_ipc_lock,cap_sys_admin+ep <executable>
+
+If physical addresses are not accessible,
+the following message will appear during EAL initialization::
+
+ EAL: rte_mem_virt2phy(): cannot open /proc/self/pagemap: Permission denied
+
+It is harmless in case PA are not needed.
+
+.. note::
+
+ Using ``vfio-pci`` kernel driver, if applicable, can eliminate the need
+ for physical addresses and therefore reduce the permission requirements.
+
+Resource Limits
+~~~~~~~~~~~~~~~
When running as non-root user, there may be some additional resource limits
that are imposed by the system. Specifically, the following resource limits may
@@ -34,8 +84,13 @@ need to be adjusted in order to ensure normal DPDK operation:
The above limits can usually be adjusted by editing
``/etc/security/limits.conf`` file, and rebooting.
-Additionally, depending on which kernel driver is in use, the relevant
-resources also should be accessible by the user running the DPDK application.
+See `Hugepage Mapping <hugepage_mapping>`_
+section to learn how these limits affect EAL.
+
+Device Control
+~~~~~~~~~~~~~~
+
+If the HPET is to be used, ``/dev/hpet`` permissions must be adjusted.
For ``vfio-pci`` kernel driver, the following Linux file system objects'
permissions should be adjusted:
@@ -45,26 +100,6 @@ permissions should be adjusted:
* The directories under ``/dev/vfio`` that correspond to IOMMU group numbers of
devices intended to be used by DPDK, for example, ``/dev/vfio/50``
-.. note::
-
- The instructions below will allow running DPDK with ``igb_uio`` or
- ``uio_pci_generic`` drivers as non-root with older Linux kernel versions.
- However, since version 4.0, the kernel does not allow unprivileged processes
- to read the physical address information from the pagemaps file, making it
- impossible for those processes to be used by non-privileged users. In such
- cases, using the VFIO driver is recommended.
-
-For ``igb_uio`` or ``uio_pci_generic`` kernel drivers, the following Linux file
-system objects' permissions should be adjusted:
-
-* The userspace-io device files in ``/dev``, for example, ``/dev/uio0``, ``/dev/uio1``, and so on
-
-* The userspace-io sysfs config and resource files, for example for ``uio0``::
-
- /sys/class/uio/uio0/device/config
- /sys/class/uio/uio0/device/resource*
-
-
Power Management and Power Saving Functionality
-----------------------------------------------
@@ -228,6 +228,8 @@ Normally, these options do not need to be changed.
can later be mapped into that preallocated VA space (if dynamic memory mode
is enabled), and can optionally be mapped into it at startup.
+.. _hugepage_mapping:
+
Hugepage Mapping
^^^^^^^^^^^^^^^^