Re: [Xen-devel] [PATCH v4] altp2m: Allow specifying external-only use-case

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 21.03.17 at 18:09, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>> On Tue, Mar 21, 2017 at 11:06 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 21.03.17 at 17:43, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>>>> On Tue, Mar 21, 2017 at 10:38 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>>> On 21.03.17 at 17:30, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>>>>>> On Tue, Mar 21, 2017 at 3:54 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>> Furthermore, wasn't HVMOP_altp2m_vcpu_enable_notify
>>>>>>> supposed to always be available to the guest (as long as altp2m
>>>>>>> is enabled)? You don't allow this here anymore.
>>>>>>
>>>>>> Absolutely not, that's one of the main reasons why I want the
>>>>>> external_only option to be available in the first place. For malware
>>>>>> analysis it is a huge hole if the guest can decide that it wants
>>>>>> certain EPT violations to be handled by the guest without first going
>>>>>> to the hypervisor or if it can start switching its EPT tables around.
>>>>>
>>>>> In which case I guess we need three modes (besides disabled):
>>>>> - guest can alter permissions
>>>>> - guest can pick tables
>>>>> - guest can do nothing
>>>>
>>>> Why do you think those other two modes would be needed? I have no
>>>> use-case for any of these other then where the guest can do nothing. I
>>>> also don't see what would be the usecase for the other two that would
>>>> warrant their addition over the mixed use that exists already.
>>>
>>> Well, "mixed" I understand is what I've listed first. And the 2nd
>>> option clearly is more secure than the first _without_ taking
>>> away all control from the guest. The set above is basically my
>>> summary of things wanted by the different parties, as I've
>>> understood the discussion so far. I quite possibly may be wrong
>>> with that ...
>>
>> I might have missed it too but I don't think there is a need for
>> config-based setup for where the guest can alter permissions but not
>> switch tables, or vice-verse. The reason I want the external mode to
>> be available as a domain config option is to avoid having to have all
>> my users custom-compile Xen from source just to enable XSM to deny
>> these altp2m hvm ops. I haven't seen anyone else having an issue with
>> just using the mixed mode as-is when using altp2m.
>
> Hmm, the original (abstract) VMFUNC use case, as I have
> understood it, allows a guest to actively select between EPT
> variants without having (direct) control over their contents.

Correct. But even when altp2m is enabled on the domain VMFUNC and #VE
is not available to the guest unless vmx_vcpu_update_vmfunc_ve is
called via HVMOP_altp2m_vcpu_enable_notify. That HVMOP is created such
that it can be called from the guest, which I need to be able to deny.

Tamas

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