Can you put

Enable=true

in the [debug] section of /etc/gdm/custom.conf, reboot, reproduce and then attach the full output of journalctl ?

Created attachment 1698949 [details]
journalctl output after enabling debug for GDM

I included output. A cursory look and it seems that it may be an SELinux problem.

indeed. if you (as a test), boot into multiuser target, then setenforce 0, then systemctl isolate graphical.target, do things start working?

I'm going to move this to the selinux-policy component, but they may refer you to the vendor. in the interm, it looks like the journal output provides a way to produce an selinux module locally that works around the issue.

setenforce 0, then systemctl isolate graphical.target allows the login screen to come up normally. I think that confirms it is a bug related to selinux.

The attached journal file contains several messages like this:

  SELinux is preventing gnome-session-c from map access on the file /memfd:/.nvidia_drv.XXXXXX (deleted)

which means that SELinux denials happened, but detailed information about these denials is missing.

Please run the following command (on the tested machine), which collects SELinux denials with all the details:

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Thank you.

Created attachment 1698990 [details]
Output of # ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Please let me know if there is anything I can do for you.

I've also reported this on the ELRepo issue tracker: https://elrepo.org/bugs/view.php?id=1022

Is this something that we can/should expect NVIDIA to resolve, or will it fall down to the users/packagers to do this? My SELinux knowledge is not that good.

========================================
*****  Plugin restorecon (92.2 confidence) suggests   ************************

If you want to fix the label. 
/memfd:/.nvidia_drv.XXXXXX (deleted) default label should be default_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted)

*****  Plugin catchall_boolean (7.83 confidence) suggests   ******************

If you want to allow domain to can mmap files
Then you must tell SELinux about this by enabling the 'domain_can_mmap_files' boolean.

Do
setsebool -P domain_can_mmap_files 1

*****  Plugin catchall (1.41 confidence) suggests   **************************

If you believe that gnome-session-c should be allowed map access on the .nvidia_drv.XXXXXX (deleted) file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'gnome-session-c' --raw | audit2allow -M my-gnomesessionc
# semodule -X 300 -i my-gnomesessionc.pp
========================================

Setting the SELinux boolean domain_can_mmap_files works around the issue:

setsebool -P domain_can_mmap_files 1

Michael Rochefort is also testing the following local SELinux policy module generated by audit2allow:

# cat nvidialocal.te

module nvidialocal 1.0;

require {
	type xserver_tmpfs_t;
	type xdm_t;
	class file map;
}

#============= xdm_t ==============
allow xdm_t xserver_tmpfs_t:file map;

I think this is the issue I referred to here: https://github.com/fedora-selinux/selinux-policy/pull/312

This policy change probably needs to be merged to RHEL.

Is there any kind of ETA when this might get fixed in RHEL? It looks like Aaron Plattner has a solution that was merged for fedora.

This bug has not been acknowledged by the selinux team to be resolved during the RHEL 8.3 development and testing phase, so it will be evaluated for inclusion into the next minor product update.

Please also note this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution.

Thank you - I have raised a support case for this issue.

Given the fix has been in fedora for the last 6 months, it would be nice if this could be resolved quickly for anyone using NVIDIA hardware.

*** Bug 1859804 has been marked as a duplicate of this bug. ***

*** Bug 1868605 has been marked as a duplicate of this bug. ***

I just verfied on RHEL8.3 pre-test version, 4.18.0-221.el8.x86_64, still found such issues.

Please Zdenek check which RHEL8.3 will merge such change.

Regards,
Jiqi.

This bug was addressed in the selinux-policy-3.14.3-51 package.

Could you please confirm which release version RHEL will include selinux-policy-3.14.3-51 rpm package, Thanks.

(In reply to Jiqi Li from comment #32)
> Could you please confirm which release version RHEL will include
> selinux-policy-3.14.3-51 rpm package, Thanks.

The fix for this bugzilla is expected to be delivered as a part of RHEL 8.3 GA. It was also scheduled for the next RHEL 8.2 batch update.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4528