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

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin


  • To: Jan Beulich <JBeulich@xxxxxxxx>, Zhongze Liu <blackskygg@xxxxxxxxx>
  • From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • Date: Thu, 19 Oct 2017 13:36:30 -0400
  • Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Thu, 19 Oct 2017 17:37:01 +0000
  • Ironport-phdr: 9a23:Rp5QgBNWMo/EwjyY6yQl6mtUPXoX/o7sNwtQ0KIMzox0K/3yp8bcNUDSrc9gkEXOFd2CrakV26yO6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fdbghMhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfOpWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnMVhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iScHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzca3HfdMeWGFPQMBfWSJcCY+4docDEfYNMeNeooLgpVUBsAG+CBGxCu3xxD9Ghnz406M03OsuEw7JwAMuEskSsHnWttj5KLseXO63waTO0D7Nb+lW2TD46IXQfB4uu/eMXbNufsrV1EIhGR3KhUiRp4z/JTyazOoNuHWc4uV9WuKglnAoqw5roje13coslonIiZ4VylDD7yl5xp01KseiRE50Zt6kDoJduieHPIV1WsMvW3xktSk1x7EcuZO3YTIGxIooyhLBcfCLbo6F6Q/5WumLOzd3nndldaq6hxa17Eev1PXxVtKx0FZWtipFlcTMtmwV2xzT9MeHTvx981+92TmVzQDT6/xEIVsumarHK58u3r4wlp0JvUTFAiD2g1n5gLWTdkUl/uik8+XnYrP4qZ+AL4J4lw7zP6s0lsG/HOg0KBYCUmeF9eimybHv5Uj5T69Ljv0ynKnZqpfaJcEDq6GkDA9az5gs6xmlDzi8y9kYgXkGI05FeBKAlYTpPUrOL+riAfewhFSsji9nx+raMb35HpXNMn/Dna/lc7tg9UFc1Q4zzdFD6JJUEbwBO+/zWlTvu9DCEhA5NAm0yf79CNphzoMeRX6PAqiBPazJtV+H/P4gI+qXZI8WuDf9JPcl6uXhjX88g1AdfK2p0YELZ3C/G/RsO1+Zbmb0gtcdDWcKuRIzTO73iF2GUD5ceXCyU7gz5jEhEo2mCYPDS5u3j7yb2Se3BIFZZmdDClqUC3fna52EW+sQaCKVOsJgnCILVbm7R48l1BGuqRH2xqF7IerV5i0Yr5Pj1ddv6+LPkhEy8CR+D96B3GGVU2F0gmQISic33K9lp0xx0FWD3rJkjPxbDtxT4PVJXxwkOp7B1eB1F9HyWh7bfteIR1eqWMmpATY0Ttgp2d8Bf159G8m+jhDExyeqGKQVl6CRC5Mv7K3c23zxJ8d7y3bHz6QhjEcpQtFJNWK4gq5z7Q/TB5TGk0+Bjaalabwc3DLR9GeE1WePs19XUAhpXarYQ38feFXZrdDi60PGTr+uEqgnMhBbxc+NNKRKbMfljVJcRPfsa5ziZDeTkmH4LxuVwrKHbMK+WU8QwSHcA0gsiB0I8DCNMg1oQm+To2XYAy5jXXbufgu4++13o3CgTV47wCmFakRg0/y+/RtD1tKGTPZG8rsCuSol4xl5VHmn1tvYQ46MqAZsc79VSc8s61dAk2TCvkpyOYL2fPMqvUIXbwki5xCm7B5wEIgV1JFw9H4=
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 10/19/2017 07:58 AM, Jan Beulich wrote:
On 19.10.17 at 04:36, <blackskygg@xxxxxxxxx> wrote:
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -516,7 +516,8 @@ static XSM_INLINE int 
xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
  static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, 
struct domain *t)
  {
      XSM_ASSERT_ACTION(XSM_TARGET);
-    return xsm_default_action(action, d, t);
+    return xsm_default_action(action, current->domain, d) ?:
+        xsm_default_action(action, current->domain, t);
  }

When all three domains are different, how does the changed
policy reflect the original "d has privilege over t" requirement?
I understand you want to relax the current condition, but this
shouldn't come at the price of granting access when access
should be denied. Nor the inverse - the current domain not
having privilege over both does also not mean d doesn't have
the necessary privilege over t.

I continue to think that you can't validly retrofit the new
intended functionality onto the existing hypercall, even if
nothing except the permission check needs to be different.

Jan

If this operation is going to be allowed at all (and I agree it has
valid use cases), then there won't be a privilege relationship between
(d) and (t) to check - they'll both be (somewhat related) domUs as far
as Xen can tell.  If this hypercall isn't used, adding a new hypercall
(subop) is the only way I'd see to do it - and that seems very redundant
as it'd need to do all the same checks except for the one about the
relationship between (d) and (t).  I don't see the reason why the
existing hypercall should deny being used for that purpose once it's
possible using other means.

The only possible problem that springs to mind is a restricted kernel
interface (such as the one used by QEMU in dom0 that restricts to a
single target domain) that now doesn't realize it's relaying an
operation that also requires permission over (t) after only checking
that the origin is allowed to modify (d).

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

 


Rackspace

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