| Message ID | 20160104130632.GF4892@mail-itl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 04, 2016 at 02:06:32PM +0100, 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. Could you post it using git-send-email please? I took a quick glance at them but didn't get a chance to do an indepth look.
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. David
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.
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
diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h index 7dc685b..312415c 100644 --- a/include/xen/interface/io/ring.h +++ b/include/xen/interface/io/ring.h @@ -198,6 +198,20 @@ struct __name##_back_ring { \ #define RING_GET_RESPONSE(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) +/* + * Get a local copy of a response. + * + * Use this in preference to RING_GET_RESPONSE() so all processing is + * done on a local copy that cannot be modified by the other end. + * + * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this + * to be ineffective where _rsp is a struct which consists of only bitfields. + */ +#define RING_COPY_RESPONSE(_r, _idx, _rsp) do { \ + /* Use volatile to force the copy into _rsp. */ \ + *(_rsp) = *(volatile typeof(_rsp))RING_GET_RESPONSE(_r, _idx); \ +} while (0) + /* Loop termination condition: Would the specified index overflow the ring? */ #define RING_REQUEST_CONS_OVERFLOW(_r, _cons) \ (((_cons) - (_r)->rsp_prod_pvt) >= RING_SIZE(_r))