lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 1 Mar 2018 09:26:48 +0100
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     Oleksandr Andrushchenko <andr2000@...il.com>
Cc:     xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, airlied@...ux.ie,
        daniel.vetter@...el.com, seanpaul@...omium.org,
        gustavo@...ovan.org, jgross@...e.com, boris.ostrovsky@...cle.com,
        konrad.wilk@...cle.com,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display
 frontend

  Hi,

> 1. Possible security issues - VirtIO devices are PCI bus masters, thus
> allowing real device (running, for example, in untrusted driver domain)
> to get control over guest's memory by writing to its memory
>
> 2. VirtIO currently uses GFNs written into the shared ring, without Xen
> grants support. This will require generic grant-mapping/sharing layer
> to be added to VirtIO.
> 
> 3. VirtIO requires QEMU PCI emulation for setting up a device. Xen PV
> (and PVH) domains don't use QEMU for platform emulation in order to
> reduce attack surface.  (PVH is in the process of gaining PCI config
> space emulation though, but it is optional, not a requirement)

Well, that is wrong.  virtio doesn't require pci.  There are other
transports (mmio, ccw), and it should be possible to create a xen
specific transport which uses grant tables properly.  Seems there even
was an attempt to implement that in 2011, see 
https://wiki.xenproject.org/wiki/Virtio_On_Xen

> 4. Most of the PV drivers a guest uses at the moment are Xen PV drivers,
> e.g. net,
> block, console, so only virtio-gpu will require QEMU to run.

You are not forced to use qemu, you can certainly create an alternative
host side implementation (and still use on the existing virtio guest
drivers).

Whenever writing a xenbus implementation for both guest and host or
writing a virtio implementation for the host only is better -- dunno.
The virtio path obviously needs some infrastructure work for virtio
support in Xen, which may pay off long term.  Your call.

cheers,
  Gerd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ