[0/8] xen: harden frontends against malicious backends

Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but it shouldn't be able to e.g. crash a guest by
other means or cause a privilege escalation in the guest).

Unfortunately many frontends in the Linux kernel are fully trusting
their respective backends. This series is starting to fix the most
important frontends: console, disk and network.

It was discussed to handle this as a security problem, but the topic
was discussed in public before, so it isn't a real secret.

Juergen Gross (8):
  xen: sync include/xen/interface/io/ring.h with Xen's newest version
  xen/blkfront: read response from backend only once
  xen/blkfront: don't take local copy of a request from the ring page
  xen/blkfront: don't trust the backend response data blindly
  xen/netfront: read response from backend only once
  xen/netfront: don't read data from request on the ring page
  xen/netfront: don't trust the backend response data blindly
  xen/hvc: replace BUG_ON() with negative return value

 drivers/block/xen-blkfront.c    | 118 +++++++++-----
 drivers/net/xen-netfront.c      | 184 ++++++++++++++-------
 drivers/tty/hvc/hvc_xen.c       |  15 +-
 include/xen/interface/io/ring.h | 278 ++++++++++++++++++--------------
 4 files changed, 369 insertions(+), 226 deletions(-)

On Thu, May 13, 2021 at 12:02:54PM +0200, Juergen Gross wrote:
> Xen backends of para-virtualized devices can live in dom0 kernel, dom0

> user land, or in a driver domain. This means that a backend might

> reside in a less trusted environment than the Xen core components, so

> a backend should not be able to do harm to a Xen guest (it can still

> mess up I/O data, but it shouldn't be able to e.g. crash a guest by

> other means or cause a privilege escalation in the guest).

> 

> Unfortunately many frontends in the Linux kernel are fully trusting

> their respective backends. This series is starting to fix the most

> important frontends: console, disk and network.

> 

> It was discussed to handle this as a security problem, but the topic

> was discussed in public before, so it isn't a real secret.


Is it based on patches we ship in Qubes[1] and also I've sent here some
years ago[2]? I see a lot of similarities. If not, you may want to
compare them.

[1] https://github.com/QubesOS/qubes-linux-kernel/
[2] https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02336.html


> Juergen Gross (8):

>   xen: sync include/xen/interface/io/ring.h with Xen's newest version

>   xen/blkfront: read response from backend only once

>   xen/blkfront: don't take local copy of a request from the ring page

>   xen/blkfront: don't trust the backend response data blindly

>   xen/netfront: read response from backend only once

>   xen/netfront: don't read data from request on the ring page

>   xen/netfront: don't trust the backend response data blindly

>   xen/hvc: replace BUG_ON() with negative return value

> 

>  drivers/block/xen-blkfront.c    | 118 +++++++++-----

>  drivers/net/xen-netfront.c      | 184 ++++++++++++++-------

>  drivers/tty/hvc/hvc_xen.c       |  15 +-

>  include/xen/interface/io/ring.h | 278 ++++++++++++++++++--------------

>  4 files changed, 369 insertions(+), 226 deletions(-)

> 

> -- 

> 2.26.2

> 

> 


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab