nvproxy additionally branches at the following points which are not covered by
the ABI struct:
1. Frontend ioctl NV_ESC_RM_ALLOC_MEMORY on
nv_ioctl_nvos02_parameters_with_fd::params::hClass.
2. Frontend ioctl NV_ESC_RM_VID_HEAP_CONTROL on NVOS32_PARAMETERS::function.
In case nvproxy doesn't implement one of the values, it should print a warning
with the same prefix of "handler is undefined" which is used for other branch
points. This will make it easier to grep for missing nvproxy functionality.
Also update documentation for nvproxy debugging. Earlier, nvproxy logged
"nvproxy: unknown ..." for such situations. That changed with 6953ca0ca3
("Add NVIDIA driver capability segmentation support to nvproxy."), which moved
to using "nvproxy: handler is undefined ...".
PiperOrigin-RevId: 726565029
e6e1ecbdcc ("Add support for graphics in nvproxy.") and 7399a32b4c ("Add
GPU video codecs support to nvproxy (so that tools like ffmpeg work)") added
support for additional driver capabilities.
PiperOrigin-RevId: 723655991
Mention two SELinux-related errors that we have seen in Fedora systems,
explain how can the user verify that they trigger them, and provide a
workaround.
The first error that we mention will be triggered by every user running
gVisor in a Fedora system, so it's good to have a solution for them. The
second error was found during the development of Dangerzone, which uses
a nested gVisor container within a rootless Podman container. This
use case is niche, but it still may help people who are experimenting
with gVisor within another container.
Refs freedomofpress/dangerzone#880
Ayush RanjanandgVisor bot
Jing ChenandgVisor bot
z63d
Lucas ManningandgVisor bot
Evan PhoenixandGitHub
Caleb Woodbine
Andrei VaginandgVisor bot
Jonathon Belotti
Kevin KrakauerandgVisor bot
Etienne PerotandgVisor bot
Alex Pyrgiotis