All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: David Vrabel <david.vrabel@citrix.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:56:28 +0100	[thread overview]
Message-ID: <20160104165628.GU4892@mail-itl> (raw)
In-Reply-To: <568A9C48.6000904@citrix.com>


[-- Attachment #1.1: Type: text/plain, Size: 1805 bytes --]

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.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-01-04 16:56 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 [this message]
2016-01-04 17:37           ` David Vrabel

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=20160104165628.GU4892@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=david.vrabel@citrix.com \
    --cc=eshelton@pobox.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.