[libvirt] New QEMU daemon for persistent reservations

[Paolo Bonzini]

On 29/08/2017 14:41, Daniel P. Berrange wrote:
> On Tue, Aug 22, 2017 at 06:27:40PM +0200, Paolo Bonzini wrote:
>> Hi all,
>>
>> I am adding a new daemon to QEMU, that QEMU can connect to in order to
>> issue persistent reservation commands.
> 
> Can you elaborate on what this daemon does ?
> 
> IIUC, by 'persistent reservation' you are referring to SCSI LUN
> reservations ?  If so, the security model needs to involve more
> than just policy on the socket that QEMU uses to talk to the
> PR daemon.  We need to be able to control what device nodes this
> daemon is permitted to access.
> 
> For iSCSI backed disks, the daemon might need to use the libiscsi
> driver, instead of assuming there is a device node on the local
> host too.

libiscsi-backed disks can already issue persistent reservations.  The
daemon is only needed for physical disks, as an alternative to
sgio='unfiltered' or (yuck) running QEMU with CAP_SYS_RAWIO.

> Libvirt has a generic lock manager facility and I've previously
> though might be able to be extended to acquire SCSI reservations
> for disks which are backed by SCSI/iSCSI, but never tried to
> work on this.

This is an interesting idea, but it is unrelated to this work, which is
about guests who manage the locking on their own (through peristent
reservations).

> I'm not sure if want to have QEMU spawning this daemon itself or not.

Definitely not.  The daemon is not suid root.

> On the one hand if QEMU spawns the daemon, then it means the daemon
> inherits the SELinux policy of QEMU by default, so is restricted to
> only access the devices that QEMU has been granted.

Libvirt could also give a confined policy to the helper, but there are
some complications because of multipath.  When passed a multipath
device, the daemon forwards the PR command to _all_ paths, not just the
currently active one, similar to the mpathpersist(1) command.  (In fact
this was the original usecase; support for non-multipath devices was
just an easy and useful extension.)

So the helper is a bit different from QEMU with respect to both SELinux
MCS labeling and the devices cgroup.  Access limitation comes from only
ever operating on devices that have been passed on the socket.  SELinux
MCS could be used so that only the "right" QEMU can connect to each
instance of the helper, though.

Paolo