From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
'Juergen Gross' <jgross@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Should PV frontend drivers trust the backends?
Date: Thu, 26 Apr 2018 08:59:42 +0300 [thread overview]
Message-ID: <dd3bbc7b-edda-22b4-955c-170e99210725@gmail.com> (raw)
In-Reply-To: <eebeb6d29e8e4b8d84c842439ffd7b8f@AMSPEX02CL03.citrite.net>
On 04/25/2018 04:47 PM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
>> Of Juergen Gross
>> Sent: 25 April 2018 13:43
>> To: xen-devel <xen-devel@lists.xenproject.org>
>> Subject: [Xen-devel] Should PV frontend drivers trust the backends?
>>
>> 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 see the general question as being analogous to 'should a Linux device driver trust its hardware' and I think the answer for a general purpose OS like linux is 'yes'.
>
> Now, having worked on fault tolerant systems in a past life, there are definitely cases where you want your OS not to implicitly trust its peripheral hardware and hence special device drivers are used.
So what do you do if counters provided by the untrusted HW are ok
and the payload is not?
> I think the same would apply for virtual machines in situations where a driver domain is not wholly controlled by a host administrator or is not trusted to the same extent as dom0 for other reasons; i.e. they should have specialist frontends.
I believe we might be able to express some common strategy for the
frontends.
I do understand though that it all needs to be decided on case by case
basis,
but common things could still be there, e.g. if prod/cons counters are
not in sync
what a frontend needs to do:
- should it keep trying to get in sync - might be a bad idea as the
req/resp data
may already become inconsistent (net can probably survive, but not
block)
- should it tear down the connection with the backend - this may
render in the whole
system instability, e.g. imagine you tear down a "/" block device
- should it BUG_ON and die
To me the second option (tear down the connection) seems to be
more reasonable, although it can still render the guest unusable, but at
least it
gives a chance for the guest to recover in a proper way
And, if my assumption is correct, we still do trust the contents of the
requests
and responses, e.g. the payload is still trusted. This also questions
the approach,
e.g. if we don't trust backend's counters, then why do we trust the
payload it sends?
And there is no obvious way to check the payload integrity.
So, either we trust the backend and accept the risks or we need to
develop some
complex approach to address the above.
Thank you,
Oleksandr
> Paul
>
>> Juergen
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xenproject.org
>> https://lists.xenproject.org/mailman/listinfo/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-04-26 5:59 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
2018-04-25 13:47 ` Paul Durrant
2018-04-26 5:59 ` Oleksandr Andrushchenko [this message]
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=dd3bbc7b-edda-22b4-955c-170e99210725@gmail.com \
--to=andr2000@gmail.com \
--cc=Paul.Durrant@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.