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

Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page


  • To: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • From: George Dunlap <george.dunlap@xxxxxxxxxx>
  • Date: Mon, 9 Jul 2018 15:48:52 +0100
  • Autocrypt: addr=george.dunlap@xxxxxxxxxx; prefer-encrypt=mutual; keydata= xsFNBFPqG+MBEACwPYTQpHepyshcufo0dVmqxDo917iWPslB8lauFxVf4WZtGvQSsKStHJSj 92Qkxp4CH2DwudI8qpVbnWCXsZxodDWac9c3PordLwz5/XL41LevEoM3NWRm5TNgJ3ckPA+J K5OfSK04QtmwSHFP3G/SXDJpGs+oDJgASta2AOl9vPV+t3xG6xyfa2NMGn9wmEvvVMD44Z7R W3RhZPn/NEZ5gaJhIUMgTChGwwWDOX0YPY19vcy5fT4bTIxvoZsLOkLSGoZb/jHIzkAAznug Q7PPeZJ1kXpbW9EHHaUHiCD9C87dMyty0N3TmWfp0VvBCaw32yFtM9jUgB7UVneoZUMUKeHA fgIXhJ7I7JFmw3J0PjGLxCLHf2Q5JOD8jeEXpdxugqF7B/fWYYmyIgwKutiGZeoPhl9c/7RE Bf6f9Qv4AtQoJwtLw6+5pDXsTD5q/GwhPjt7ohF7aQZTMMHhZuS52/izKhDzIufl6uiqUBge 0lqG+/ViLKwCkxHDREuSUTtfjRc9/AoAt2V2HOfgKORSCjFC1eI0+8UMxlfdq2z1AAchinU0 eSkRpX2An3CPEjgGFmu2Je4a/R/Kd6nGU8AFaE8ta0oq5BSFDRYdcKchw4TSxetkG6iUtqOO ZFS7VAdF00eqFJNQpi6IUQryhnrOByw+zSobqlOPUO7XC5fjnwARAQABzSRHZW9yZ2UgVy4g RHVubGFwIDxkdW5sYXBnQHVtaWNoLmVkdT7CwYAEEwEKACoCGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4ACGQEFAlpk2IEFCQo9I54ACgkQpjY8MQWQtG1A1BAAnc0oX3+M/jyv4j/ESJTO U2JhuWUWV6NFuzU10pUmMqpgQtiVEVU2QbCvTcZS1U/S6bqAUoiWQreDMSSgGH3a3BmRNi8n HKtarJqyK81aERM2HrjYkC1ZlRYG+jS8oWzzQrCQiTwn3eFLJrHjqowTbwahoiMw/nJ+OrZO /VXLfNeaxA5GF6emwgbpshwaUtESQ/MC5hFAFmUBZKAxp9CXG2ZhTP6ROV4fwhpnHaz8z+BT NQz8YwA4gkmFJbDUA9I0Cm9D/EZscrCGMeaVvcyldbMhWS+aH8nbqv6brhgbJEQS22eKCZDD J/ng5ea25QnS0fqu3bMrH39tDqeh7rVnt8Yu/YgOwc3XmgzmAhIDyzSinYEWJ1FkOVpIbGl9 uR6seRsfJmUK84KCScjkBhMKTOixWgNEQ/zTcLUsfTh6KQdLTn083Q5aFxWOIal2hiy9UyqR VQydowXy4Xx58rqvZjuYzdGDdAUlZ+D2O3Jp28ez5SikA/ZaaoGI9S1VWvQsQdzNfD2D+xfL qfd9yv7gko9eTJzv5zFr2MedtRb/nCrMTnvLkwNX4abB5+19JGneeRU4jy7yDYAhUXcI/waS /hHioT9MOjMh+DoLCgeZJYaOcgQdORY/IclLiLq4yFnG+4Ocft8igp79dbYYHkAkmC9te/2x Kq9nEd0Hg288EO/OwE0EVFq6vQEIAO2idItaUEplEemV2Q9mBA8YmtgckdLmaE0uzdDWL9To 1PL+qdNe7tBXKOfkKI7v32fe0nB4aecRlQJOZMWQRQ0+KLyXdJyHkq9221sHzcxsdcGs7X3c 17ep9zASq+wIYqAdZvr7pN9a3nVHZ4W7bzezuNDAvn4EpOf/o0RsWNyDlT6KECs1DuzOdRqD oOMJfYmtx9hMzqBoTdr6U20/KgnC/dmWWcJAUZXaAFp+3NYRCkk7k939VaUpoY519CeLrymd Vdke66KCiWBQXMkgtMGvGk5gLQLy4H3KXvpXoDrYKgysy7jeOccxI8owoiOdtbfM8TTDyWPR Ygjzb9LApA8AEQEAAcLBZQQYAQoADwUCVFq6vQIbDAUJAeEzgAAKCRCmNjwxBZC0bWknD/97 Tkh3PMAcvMZINmJefBdYYspmwTWZSR9USsy68oWzDsXKNDNTqBC781lR/7PSqhqaSOmSnty3 FNblaBYKfMV3OOWgrP0H8Voqp4IgH3yOOkQLVITIwulqbbxQtmCsJ3xkhZm6CA0EKbc9VM/j FX3aCAfOJf52vlY1gXjYOvVjrdrRrBXEjs8E5f6EsrQKDrWCKNx/9qRfmtsQeKHTsgpINkpZ s11ClX/sM/RCR9/BgB/K08QQZYsWD6lgZh1KxLXRzKRunba0L+jpcRsoQFUMj/ofrfnHAdl0 q2upzISM/wR8aer+kekMo+y00schmYJYu5JAAzbjQQuhCAg0UTBGPaNwteL2l3c9Ps8on1nl mq9TnbYwGLAxJzXSb3BATgz7dygpsBBNS5WhUNQgIJvcZJbLggEIqjZGs8o7/+dt4klwxCYL FVlsWYSwEjX0UYHVLMS/F7FcXbCMUeoN/4krmRyv7YICE/VDQSDPcSKedzWvQM8T+5uY5pFJ NiIaa6asFndP50GiKbFtD6xAM+rbnwT7Io+iPtvD/3ddMXQs58IVMzgNA/hcdOX/qlx6Jqk/ hYQQsl4HoQsx/GyrNiwiPErTx32QNeXxoGYm6kwxt7F5qK7AN5tyYNkEyoxYrv8bl9VjAve8 hpECyf4O1mOGC/dIuBCDk8gxL5Pbo3jl98LBZQQYAQoADwIbDAUCVlNqsQUJA9njdAAKCRCm NjwxBZC0bbJMEACigmtpL2lzS47DXydApr1X8SYCHIPc39OjvmErjP05lKUZjmesmhlM5eKO gPb/fzeJ0wXB4J8OyseIJ0D/XwyLLQeM8d/HUFFMBWr+HE7jIukAUXeQ6GRwR+MBYGK/KmR9 JHbMAUz8f3G087Ma12BfpNWayndlFwR3rvdV4lvlyx6cl0EaFhbzPu/N07HG5MTk0evtphgZ 7wuG1oAtO+DGA6orHEicor6nBAQNZzPyjqo40dBxTs+amx7UndMRPSL1dD57eJwbbvBeNa8I w8wT7oNy2/C21VWmSy5XzMzcUTgmjmQz6DSNJPz2dMK4Y/LtcVFTfSZTmlBIkfoc9Vay2EB9 3z2EmjZwGT7n/DRu9QDtLbXyeVTBuLTaP3D+q5AyR1/5Z4T0LhwNvxeND5yO+YNAwqocZwL+ OcctpSZUBpAuU4Ju/9JKMX57GlnbjB8YGahoBJsQZx4CZyw0MXlkCk5cR0EPjY9iI2CEA5lO QueOSbo0hf1ZJwCx724lx0WSwL8ngd8wZTYMNc8GngaU61kmzfcuCklhokTxQdK7Efme5ccv A1txzgGewx9mDhPgNcJweasBnyL0N3wya2RMAzm04gCio8y4FKQepwQpKCNKAYZIU4juAPxn nb6cbBGiMGO1NDuxG+qvl1cMElnq+cuhSUlZdr2sE9JRfa0gucLBZQQYAQoADwIbDAUCWHQN VAUJBfqGFwAKCRCmNjwxBZC0bbgCD/oC6mWUrxQKWPDvFE9+fzm8UKqKP7aciz+gvWUN3o4i 4sRFNyvAEOW/QY2zwM1pN07BFZ3Z+8AVxpgR6h7RQzDJYSPZ5k5WWCJzJEQs2sPI5rfYJGK8 um7mlsSvf2xcLK/1Aj07BmWDjR6glDDRY+iMmSSdHe6Te6tiQPPS6Woj8AE3qf5lBsdvcEln nrkSwzNeVKRQQROUOskVw4WmCsNJjZtKmrVpgId3df/5HWG7Bi4nPwA8IFOt6O72lJlkORFy DF5P7ML7Pc5LbEFimzETPBxTJzVu1UoOQb/THB+qxhKMXXudSf/5sdMhwvOwItIcc5pib/v6 7gWK48bAzoOTgNYzmDCVC/roeLLU2SpEQIlIR0eAaWImgt8VEtre3Gch33e41DtbUli54DX0 dRdhqQaDM1T1q77VyDoZcs+SpGX9Ic9mxl+BN+6vtGIUVgaOG5pF85aQlRfCD6IlFQgiZtiR XeRpeIYG27RUw5kIljW+VxPMdBUvZpUXEazqjoPvBKybg0oKFfMXrMj4vHo6J0FD3ZEToGnP dANspUCZRewRozjp7ZWIu7QfGasfJNQ8c1IDiAFl3rV+dAGXXdmrDcX6w2q5lqoFz+8npK2I ehKCA94U+J/RLywUiaLuHnXt40WvQ98kHm7uTsy36iWqqawPqzmn8m5ruynVHmmcXsLBZQQY AQoADwIbDAUCWmTXMwUJB+tP9gAKCRCmNjwxBZC0bb+2D/9hjn1k5WcRHlu19WGuH6q0Kgm1 LRT7PnnSz904igHNElMB5a7wRjw5kdNwU3sRm2nnmHeOJH8kYj2Hn1QgX5SqQsysWTHWOEse GeoXydx9zZZkt3oQJM+9NV1VjK0bOXwqhiQyEUWz5/9l467FS/k4FJ5CHNRumvhLa0l2HEEu 5pxq463HQZHDt4YE/9Y74eXOnYCB4nrYxQD/GSXEZvWryEWreDoaFqzq1TKtzHhFgQG7yFUE epxLRUUtYsEpT6Rks2l4LCqG3hVD0URFIiTyuxJx3VC2Ta4LH3hxQtiaIpuXqq2D4z63h6vC x2wxfZc/WRHGbr4NAlB81l35Q/UHyMocVuYLj0llF0rwU4AjiKZ5qWNSEdvEpL43fTvZYxQh DCjQTKbb38omu5P4kOf1HT7s+kmQKRtiLBlqHzK17D4K/180ADw7a3gnmr5RumcZP3NGSSZA 6jP5vNqQpNu4gqrPFWNQKQcW8HBiYFgq6SoLQQWbRxJDHvTRYJ2ms7oCe870gh4D1wFFqTLe yXiVqjddENGNaP8ZlCDw6EU82N8Bn5LXKjR1GWo2UK3CjrkHpTt3YYZvrhS2MO2EYEcWjyu6 LALF/lS6z6LKeQZ+t9AdQUcILlrx9IxqXv6GvAoBLJY1jjGBq+/kRPrWXpoaQn7FXWGfMqU+ NkY9enyrlw==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Adrian Pop <apop@xxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 09 Jul 2018 14:49:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 07/09/2018 12:53 PM, Razvan Cojocaru wrote:
> On 07/09/2018 02:46 PM, George Dunlap wrote:
>> On 07/09/2018 12:18 PM, Razvan Cojocaru wrote:
>>> On 07/09/2018 02:04 PM, George Dunlap wrote:
>>>> On 07/06/2018 05:52 PM, Tamas K Lengyel wrote:
>>>>> On Fri, Jul 6, 2018 at 2:56 AM Razvan Cojocaru
>>>>> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>> On 07/05/2018 07:45 PM, Tamas K Lengyel wrote:
>>>>>>> On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru
>>>>>>> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>>>>> However, our particular application is only interested in setting (and
>>>>>>>> querying) page restrictions from userspace (from the dom0 agent). It
>>>>>>>> will also need to be able to set the convertible bit of guest pages 
>>>>>>>> from
>>>>>>>> the dom0 agent as well (patches pending). So we're also fine with a
>>>>>>>> "DOMCTL if nobody wants it as a HVMOP" policy, if polluting the DOMCTLs
>>>>>>>> (possibly temporarily) is an option.
>>>>>>>>
>>>>>>>> We could also (at least between Tamas and us) come up with current /
>>>>>>>> likely use-cases and downgrade all altp2m HVMOPs that could be DOMCTLs
>>>>>>>> in all the scenarios to DOMCTLs.
>>>>>>>
>>>>>>> Aye. There is really just one HVMOP that the guest absolutely needs
>>>>>>> access to so that it can use #VE, and that's
>>>>>>> HVMOP_altp2m_vcpu_enable_notify. AFAIU everything else could be just a
>>>>>>> DOMCTL.
>>>>>>
>>>>>> We need even less than that - we want to modify
>>>>>> HVMOP_altp2m_vcpu_enable_notify to be able to call it from dom0 as well,
>>>>>> and we don't call it from the in-guest agent ever. Because we agree that
>>>>>> the smallest attack surface is a requirement, all we ever call that's
>>>>>> #VE / altp2m related is actually from the privileged domain doing
>>>>>> introspection. The in-guest driver only needs to do VMFUNC and be able
>>>>>> to communicate with the dom0 introspection agent.
>>>>
>>>> For some reason my impression was that Intel was hoping to be able to
>>>> enable a guest-only usage as well -- that basically a guest which had
>>>> been booted (say) with measured boot, and then wrote its own enclave
>>>> using #VE and altp2ms, should be able to allow an in-guest agent to be
>>>> reasonably secure and also keep tabs on the operating system.  Was this
>>>> not your impression?
>>>
>>> The wording on their initial design document does say:
>>>
>>> "- Hypercalls for altp2m
>>>
>>> Altp2m mode introduces a new set of hypercalls for altp2m management
>>> from software agents operating in Xen HVM guests.
>>>
>>> The hypercalls are as follows:
>>>
>>> Enable or Disable altp2m mode for domain
>>> Create a new alternate p2m
>>> Edit permissions for a specific GPA within an alternate p2m
>>> Destroy an existing alternate p2m"
>>>
>>> But I've always suspected that it might have been just what they have
>>> thought would offer the most possibilities.
>>>
>>> The problem with in-guest agents doing all these things is that it kind
>>> of kills the whole "the introspection cannot be stopped or manipulated
>>> at all from within the guest" assumption that gives hypervisor-level
>>> introspection its edge - because then it's possible for in-guest code to
>>> bypass dom0-based introspection by simply switching to a non-restricted
>>> EPTP index, or editing the restricted pages permissions. And we're back
>>> to in-guest protection.
>>
>> I don't think you've quite gotten the design in mind here.  The idea is
>> that *all* of the "introspection" happens inside the guest.  The guest
>> agent is given all the tools it needs to protect itself even from the
>> guest operating system.  Just having a chat with Andy, apparently Intel
>> actually had just such an agent once upon a time, and used this
>> interface on Xen for real.
>>
>> I think there are advantages to each model.  Obviously having something
>> run in the guest means that if someone manages to mess with your disk
>> and then cause you to reboot, it's pretty close to game-over.  But one
>> of the advantages is that it wouldn't rely on the host administrator to
>> install your introspection engine -- you could have a cloud provider
>> simply expose the altp2m functionality, and then each person could have
>> their own in-guest agent as they want.
>>
>> And although arguably the in-guest agent is less secure from *being*
>> attacked, it does mean that the system as a whole is more secure.
>> Having an agent in dom0 means that if you compromise the dom0 agent, you
>> now have complete access to the entire system; whereas compromising your
>> in-guest agent gives you only control over that guest, no other guests
>> on the system.
>>
>>> The in-guest agent should in our view be an optimization-only, not
>>> something allowed to make its own decisions about the introspection process.
>>
>> I think having an interface which allows an only-in-guest-agent makes
>> sense -- particularly as one instance has already been made.  If it were
>> entirely up to me, I'd leave the interface, so that it's there for
>> someone later to pick up if they want to.
> 
> That is all well argued, and is fair enough.
> 
> All I was really trying to point out was that we're happy with either
> DOMCTL or HVMOPs for this (and it looks like Tamas as well) - the actual
> point is to just try and settle this once for all so that altp2m
> development can go forward (because really at this point its de-facto
> blocked for unreasonably long ammounts of time by the design debate, on
> every patch adding or modifying an operation).

Sure, it's certainly unpleasant, and unfair, every time you want to
extend the interface for your own use case, to get into a big argument
about what should happen with respect to some other use case, which not
only *you* aren't using, but it would seem, *nobody* at the moment is
using.

And I remember now, the last time this came up you wanted to add a new
subop, and Jan said it should be a domctl unless we knew we wanted to
expose it to the guest, and Andy said it should be with all the other
functionality (i.e., an hvmop).

This is just silly.  We already decided they should all be HVMOPs.  If
we want to disable ALTP2M_mixed mode until someone wants to audit it --
or whitelist only the curret functionality -- that's one thing.  But we
shouldn't make a second hypercall for non-guest-accessible
functionality, nor should we even consider changing the current HVMOP
into a DOMCTL.  Absolutely not.

We do need to stop having pointless arguments, however.  Let me see what
I can come up with.

 -George

_______________________________________________
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®.