[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v9 1/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
  • From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • Date: Fri, 7 Dec 2018 14:33:08 -0500
  • Cc: Stefano Stabellini <stefanos@xxxxxxxxxx>, wei.liu2@xxxxxxxxxx, blackskygg@xxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, ian.jackson@xxxxxxxxxxxxx, Tim Deegan <tim@xxxxxxx>, julien.grall@xxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>
  • Delivery-date: Fri, 07 Dec 2018 19:33:37 +0000
  • Ironport-phdr: 9a23:IshWrxNPcsLukACUXIMl6mtUPXoX/o7sNwtQ0KIMzox0K/n6psbcNUDSrc9gkEXOFd2Cra4c26yO6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglUhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iScHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzca3HfdMeWGFPQMBfWSJcCY+4docDEvYNMeNeooLgpVUBsAG+CBGxCu3xxD9Ghnz406M03OsuEw7JwAMuEskSsHnWttj5KLseXO63waTO0D7Nb+lW2TD46IXQfB4uu/eMXbNufsrV1EIhGR3KhUiRp4z/JTyazOoNuHWc4uV9WuKglnAoqw5roje13coslonIiZ4VylDD7yl5xp01KseiRE50Zt6kDoJduieHPIV4RcMiRntnuCc8yrAetp+0Yi4KxI4gxx7FZPyKdZWD7BH7VOuJPDt1i31odKi/ihqv60Ss1OLxWteu3FpXqCdOj8PCuWoX1xPJ78iKUv59/kC81jmRzw3T8eREIVwslarcNp4h3qY8lpoNvkTHGS/7gFn2g7WMdkUl5+io8P7rYqnmp5CAN490jRvyMqIylcykHes0KA0OX2mf+eik1b3j+1P2QKlSg/ErnaTUv4rWKMQGqqKjHQNY3Zgv5wyiAzu+1dQXh3gHLFZLeBKdiIjpPknDL+33DfiinVusny1ryOrdM739ApTCMnjDkLD7cbZ78E5T0hA/zd9Y55JKEr0BOu78WlfttNzECR80Kxe0w/37CNpnzYwRR2aPAquYMKPUsF+F/eEvLPeWZI8Tpjn9L+Ip5/n0jX82gVUdZ7Wm3YMLaHCkGfRrO0qYbmTqgtsYDGgFoBQ+Q/LuiFCZVT5TZm2yX74n5j0hB4OpE4HDSpqqgLyb0yexBodWaXxeClCQDXfocJ2JVOwIaC2IPsBhkScEVbuhSo8u2hGjrwD6y799IerV/i0Ur47s1N9w5+fLjxE96SR0D9iB02GKV2x0nH4IRzs33K9hp0xx0FiD0bJijPxcEdxe/OlGUh0/NZLG0+N6DNXyUBrbftiVUFamXsmmATYpQ9M/3dAOYlxxG9GjjhDewSanGKMal72XBJwu86Ld0GL9KNp6y3bDzKMhlUUpQtNTNW26ga5y7wnTCJTPk0mDlaalb7gT3C3W9GeEy2qDp19XUBNqXarZXHAfelHWrdX250/YU7CuDrEnOBNbycGeMqtKdsHpjVJeSff4JNTRfWyxlH22BRaP3bOBd4Xre2QZ3CXcDkgFnBof8mqBNQg7Hi2huX7RDCRyFVLzZEPh6fNxqHWmQU8u0Q6LYVdt2Kay+h4SnfyTVekT07wftSg9qjV0AEy939PZCtaauwVhe6Bca8sn4FhbzWLZqxB9Ppu4Iq5jmFEedB53v0zw2BltBItAjM4qrHcwwwpqMq+Xzk5BeymE0pDxJr3XMGjy/R+1Z6HK3VHe1c6c+r0T5/Qgt1XjoAapG1Ig83p8zdZVzn+c5pTWAwoSSp/xSVs39wNkqL3AfiY94IbU32V2Maaoqj/Cx84pBOw9xxajeNdfNrmEGxXvHMEACcmuKegqm1uyYxIDJuBd7rI7P8e4ePecxKGrO+Ngliq8jWtb+IB9zl6M9y1kR+7U3pYFxuqV3wSZWDf6lluhtdr3mY8XLQ0VS1GjxCbtAokZXbF7d4sPDWaoIoXj3c5ijpTgX3pZ8l+LBF4c3sKtPx2IYAq5lR1d0wEbrGKqnQO8zidoiHc5o6zZ2zbBkMr4cx9SFmdNRWRmxXvhaaeuhtkUFBykYAQkmwGszVrrzKhc4qJkJi/cRlkeLHu+FH1rTqbl7unKWMVI8p599HwOCOk=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12/5/18 5:15 PM, Stefano Stabellini wrote:
From: Zhongze Liu <blackskygg@xxxxxxxxx>

The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.

This patch introduces XENMAPSPACE_gmfn_share to address this inconvenience,
which is mostly the same as XENMAPSPACE_gmfn_foreign but has its own xsm check.

Specifically, the patch:

* Introduces a new av permission MMU__SHARE_MEM to denote if two domains can
   share memory by using the new subop;
* Introduces xsm_map_gmfn_share() to check if (current) has proper permission
   over (t) AND MMU__SHARE_MEM is allowed between (d) and (t);
* Modify the default xen.te to allow MMU__SHARE_MEM for normal domains that
   allow grant mapping/event channels.

The new subop is marked unsupported for x86 because calling p2m_add_foregin
on two DomU's is currently not supported on x86.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu <blackskygg@xxxxxxxxx>
Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>[...]
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b0ac1f6..9d109b0 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -535,6 +535,20 @@ static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG 
struct domain *d, str
     return xsm_default_action(action, d, t);
 }
+/*
+ * Be aware that this is not an exact default equivalence of its flask
+ * variant which also checks if @d and @t "are allowed to share memory
+ * pages", for now, we don't have a proper default equivalence of such a
+ * check.
+ */
+static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain *d,
+                                         struct domain *t)
+{
+    XSM_ASSERT_ACTION(XSM_TARGET);
+    return xsm_default_action(action, current->domain, d) ?:
+           xsm_default_action(action, current->domain, t);
+}

In all of the callers that I checked, we've already made a call to the
xsm_add_to_physmap hook checking that (current) can modify (d), so the
check here is redundant.  If it's useful to keep the redundant check in
case another caller is added later (or if there's one I missed), it would
also be useful to re-verify the MMU__PHYSMAP permission in the flask code
so that the checks remain equivalent.

If you want the comment on the (d,t) check documented in code, the XSM_HOOK
action is a useful no-op.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.