From: David Vrabel <david.vrabel@citrix.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: security@xen.org,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Eric Shelton <eshelton@pobox.com>
Subject: Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory
Date: Mon, 4 Jan 2016 17:37:37 +0000 [thread overview]
Message-ID: <568AADE1.4070107@citrix.com> (raw)
In-Reply-To: <20160104165628.GU4892@mail-itl>
On 04/01/16 16:56, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 04, 2016 at 04:22:32PM +0000, David Vrabel wrote:
>> On 04/01/16 13:06, Marek Marczykowski-Górecki wrote:
>>> On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote:
>>>> The XSA mentions that "PV frontend patches will be developed and
>>>> released (publicly) after the embargo date." Has anything been done
>>>> towards this that should also be incorporated into MiniOS? On a
>>>> system utilizing a "driver domain," where a backend is running on a
>>>> domain that is considered unprivileged and untrusted (such as the
>>>> example described in http://wiki.xenproject.org/wiki/Driver_Domain),
>>>> it seems XSA-155-style double fetch vulnerabilities in the frontends
>>>> are also a potential security concern, and should be eliminated.
>>>> However, perhaps that does not include pcifront, since pciback would
>>>> always be running in dom0.
>>>
>>> And BTW the same applies to Linux frontends, for which also I haven't seen
>>> any public development. In attachment my email to
>>> xen-security-issues-discuss list (sent during embargo), with patches
>>> attached there. I haven't got any response.
>>
>> There are no similar security concerns with frontends since they trust
>> the backend.
>>
>> I note that you say:
>>
>> "But in some cases (namely: if driver domains are in use), frontends
>> may be more trusted/privileged than backends."
>>
>> But this cannot be the case since the backend can always trivially DoS
>> the frontend by (for example) not unmapping grant references when
>> required by the protocol.
>
> DoS is one thing, code execution is another.
The DoS is a trivial and obvious example to illustrate that your
suggestion that:
"...frontends may be more trusted/privileged than backends."
is ill-advised.
Anyway, none of this means we won't consider your netfront patches. But
you do need to post them to the correct lists (netdev and xen-devel).
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-01-04 17:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 23:10 Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory Eric Shelton
2015-12-22 12:24 ` Stefano Stabellini
2015-12-22 13:19 ` Samuel Thibault
2015-12-22 15:06 ` Eric Shelton
2016-01-04 13:06 ` Marek Marczykowski-Górecki
2016-01-04 15:00 ` Konrad Rzeszutek Wilk
2016-01-04 16:22 ` David Vrabel
2016-01-04 16:56 ` Marek Marczykowski-Górecki
2016-01-04 17:37 ` David Vrabel [this message]
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=568AADE1.4070107@citrix.com \
--to=david.vrabel@citrix.com \
--cc=eshelton@pobox.com \
--cc=marmarek@invisiblethingslab.com \
--cc=security@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.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.