Nvidia's Linux driver now uses the kernel call its own engineer said reviewers objected to
Nvidia's Linux display driver 615.78.08, published on October 7, now parks the contents of GPU memory in a kernel-private file that SELinux never inspects, using shmem_kernel_file_setup(), the kernel call an Nvidia engineer told Fedora's maintainers in August that reviewers had objected to. The switch is visible in Nvidia's own public source tree, which calls shmem_file_setup at tag 615.71.09 and the new function at 615.78.08, both read at 21:08 UTC on October 8.
The scratch file holds GPU memory contents while a desktop is asleep. Image: Nvidia
The file exists to hold video memory while a machine sleeps, when video-memory preservation is switched on. Older drivers opened a real file under /tmp, movable with the NVreg_TemporaryFilePath parameter, and 615.71.09 had already moved the default to an anonymous shmem file. The difference now is the inode: the new call marks it S_PRIVATE, so security modules skip it entirely rather than labelling it like any other tmpfs file.
For an owner the consequence is suspend itself. Nvidia's filing describes a machine that fails to go to sleep once the driver runs that code inside systemd's very restrictive sleep context, where the old filesystem access is blocked.
Fedora's maintainer proposed the call Nvidia had set aside
Nvidia opened the underlying report against Fedora's selinux-policy package on August 6, warning that a coming driver would move this work into the kernel's response to a write to /sys/power/state. On August 15 a Fedora SELinux maintainer answered in Red Hat Bugzilla 2512142 that if the file never left kernel space, "the driver should instead open it via shmem_kernel_file_setup(), which will mark the inode with S_PRIVATE, making it bypass security module checks (as is the norm for purely kernel-private files)".
Two days later an Nvidia engineer confirmed the file is kernel-only and then ruled the suggestion out. "I did look at shmem_kernel_file_setup() when I was working on the initial version of the change, but reviewers objected to using it to bypass LSM checks because the documentation mentions specifically that bypassing LSM is not its intended use," the reply reads, quoting the kernel's own warning that there are no LSM permission checks against the underlying inode.
On September 3 the same account wrote "I managed to work around this in the driver, so I think this can be closed", and the report was closed with resolution UPSTREAM. Nvidia's pull request against selinux-policy, "Allow fs_write_tmpfs_files for systemd_sleep_t", open since March 3, was closed without being merged at 23:38 UTC that evening, under two minutes before that comment landed. Both were read at 21:08 UTC on October 8.
The driver's own code spells out the trade
615.78.08 adds a comment to that function which 615.71.09 does not carry. The file, it says, "may bypass LSM checks such as SELinux, so it is important that this file never be mapped, linked into the filesystem, or assigned a file descriptor unless access control is checked by the caller".
Not every machine takes the new route. The build file nvidia.Kbuild gains a compile-time probe for the symbol in 615.78.08 and carries none at 615.71.09, so the driver falls back to the old shmem_file_setup call on kernels that do not export shmem_kernel_file_setup. Which path a given system uses therefore depends on its kernel, not on its driver version.
The release also turns NVreg_UseKernelSuspendNotifiers on by default, which is the switch that sends suspend through this code at all, so machines that never had the triggering option enabled now have it enabled. The rest of what 615.78.08 changes runs to six items. The call Nvidia set aside in August is the one its driver has been shipping since October 7.
