All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <jgross@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Should PV frontend drivers trust the backends?
Date: Wed, 25 Apr 2018 14:36:11 +0100	[thread overview]
Message-ID: <4c1d0926-e76d-15a7-4f11-044826c08fb7@citrix.com> (raw)
In-Reply-To: <9ab3e669-787b-ef4d-b672-9bbf5dcb5f14@suse.com>

On 25/04/18 13:42, Juergen Gross wrote:
> This is a followup of a discussion on IRC:
>
> The main question of the discussion was: "Should frontend drivers
> trust their backends not doing malicious actions?"
>
> This IMO includes:
>
> 1. The data put by the backend on the ring page(s) is sane and
>    consistent, meaning that e.g. the response producer index is always
>    ahead of the consumer index.
>
> 2. Response data won't be modified by the backend after the producer
>    index has been incremented signaling the response is valid.
>
> 3. Response data is sane, e.g. an I/O data length is not larger than
>    the buffer originally was.
>
> 4. When a response has been sent all grants belonging to the request
>    have been unmapped again by the backend, meaning that the frontend
>    can assume the grants can be removed without conflict.
>
> Today most frontend drivers (at least in the Linux kernel) seem to
> assume all of the above is true (there are some exceptions, but never
> for all items):
>
> - they don't check sanity of ring index values
> - they don't copy response data into local memory before looking at it
> - they don't verify returned data length (or do so via BUG_ON())
> - they BUG() in case of a conflict when trying to remove a grant
>
> So the basic question is: should all Linux frontend drivers be modified
> in order to be able to tolerate buggy or malicious backends? Or is the
> list of trust above fine?
>
> IMO even in case the frontends do trust the backends to behave sane this
> doesn't mean driver domains don't make sense. Driver domains still make
> a Xen host more robust as they e.g. protect the host against driver
> failures normally leading to a crash of dom0.

I think the issue here is that "trust" is actually two different thing here.

If we consider "the ring" as an opaque transport layer, then I expect
both sides to be resilient to a buggy/malicious other end.  I realise
this is not currently the case, but I think it should be reasonable to
hook either side up to AFL and not have the other side crash. 
(Declaring the other half insane and transitioning to closed is an
entirely reasonable action.)

When it comes to the data content served by "the opaque ring", then
trust is far more complicated thing.

If blkback is serving /, then the default case has little option but to
trust the other end.  This is clearly how the frontends have been developed.

However, non-default cases might include using an encrypted filesystem,
at which point the domU isn't in the position of having to trust the
driver domain serving its filesystem, and therefore shouldn't be forced
into trusting the backend simply because it doesn't protect itself
against pitfalls which inherently come from using shared memory interfaces.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-04-25 13:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 12:42 Should PV frontend drivers trust the backends? Juergen Gross
2018-04-25 13:36 ` Andrew Cooper [this message]
2018-04-25 13:47 ` Paul Durrant
2018-04-26  5:59   ` Oleksandr Andrushchenko
2018-04-26  8:16     ` Paul Durrant
2018-04-26  8:47       ` Oleksandr Andrushchenko
2018-04-30 17:32         ` Marek Marczykowski-Górecki
2018-05-01  7:55           ` Paul Durrant
2018-05-01 15:00             ` 'Marek Marczykowski-Górecki'
2018-05-01 15:32               ` Paul Durrant
2018-04-26  8:46   ` Petr Tesarik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c1d0926-e76d-15a7-4f11-044826c08fb7@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=jgross@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.