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

[Sergej Proskurin <proskurin@xxxxxxxxxxxxx>]

Hi all,

as I am currently working on a concept that uses the #VE functionality
from inside of the unprivileged guest domain myself, I would like to add
my opinion to the discussion.


On 07/09/2018 07:53 AM, 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?

I absolutely agree upon that Intel was building a system that allows
guest domains to enable and control the #VE (including the funcitonality
to set up different altp2ms). Although this functionality has not been
widely adopted (yet?), I personally would prefer a hybrid solution that
does not completely prohibit this concept from inside of the
unprivileged guest domain. I agree with Tamas upon the fact that some
concepts can be equally implemented by using the guest's page tables
only. However, (I understand that I am biased, as I am working on a
concept that makes use of this functionality from inside of domu), I
also believe that we can apply the functionality given by #VE and VMFUNC
from inside the guest to harden certain system resources. As such, I
would be happy to see a hybrid solution that allows this feature to be
configured either for unlimited or for external use only.

Best,
~Sergej



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