Bug 1665469

Summary:	(AMD SEV) Overly restrictive permissions on the /dev/sev device
Product:	Red Hat Enterprise Linux 8	Reporter:	Erik Skultety <eskultet>
Component:	systemd	Assignee:	Jan Synacek <jsynacek>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	8.0	CC:	eskultet, jsynacek, rbalakri, systemd-maint-list, virt-bugs, wchadwic
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1665400	Environment:
Last Closed:	2019-01-24 16:05:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1654309, 1665400, 1671791

Description Erik Skultety 2019-01-11 14:04:34 UTC

+++ This bug was initially created as a clone of Bug #1665400 +++

Description of problem:
Libvirt reports <sev supported='no'/> even though SEV is enabled on the platform, i.e. both the cpuflags contain 'sev' and /dev/sev exists on the filesystem. 

Version-Release number of selected component (if applicable):
4.5.0-17.module+el8+2625+db702f9d

How reproducible:


Steps to Reproduce:
1. enable SEV on the platform so that /dev/sev appears on the filesystem
2. install libvirt, launch libvirtd
3. run virsh domcapabilities, the output contains:
...
<sev supported='no'/>
...

Actual results:
Libvirt is unable to launch a SEV VM because it reports the feature as unsupported

Expected results:
Libvirt is able to launch a SEV VM

Additional info:
1) Going through libvirt debug logs, one can also see that the error is coming from QEMU when probing for capabilities:

debug : qemuMonitorJSONIOProcessLine:197 : Line [{"id": "libvirt-53", "error": {"class": "GenericError", "desc": "SEV feature is not available"}}]

2) Even though 1) suggests this might be a bug in QEMU, the problem are the default permissions on /dev/sev:

# ls -l /dev/sev
crw-------. 1 root root

which is a problem because when libvirt probes QEMU for capabilities, the process runs as qemu:qemu by default.

Comment 6 Jan Synacek 2019-01-15 09:54:30 UTC

See also https://bugzilla.redhat.com/show_bug.cgi?id=1663329.

Comment 8 Erik Skultety 2019-01-18 10:43:47 UTC

There's been a turn of events in virt (libvirt+QEMU) which resulted in me starting an upstream discussion here:
https://www.redhat.com/archives/libvir-list/2019-January/msg00630.html which means that having an udev rule for /dev/sev might actually not turn up to be a good idea. It mainly depends on the input we get from AMD developers.

Comment 9 Jan Synacek 2019-01-18 10:45:54 UTC

Ok. From systemd's point of view, the patch is trivial. Please, let us know about the final decision.

Comment 10 Erik Skultety 2019-01-24 16:05:40 UTC

Closing as WONTFIX for now, since there is a potential security risk even with a 0644 rule at the moment. This needs to be addressed in kernel first. I'll reopen in the future if necessary.