Re: [Xen-devel] [PATCH V2] common/mem_access: merged mem_access setting interfaces

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Mon, Mar 20, 2017 at 8:20 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

On 20/03/17 09:50, Razvan Cojocaru wrote:
> xc_altp2m_set_mem_access() and xc_set_mem_access() end up doing the same thing
> in the hypervisor, but the former is a HVMOP and the latter a DOMCTL. Since
> nobody is currently using, or has stated intent to use, this functionality
> specifically as an HVMOP, this patch removes the HVMOP while adding an extra
> parameter to the more flexible DOMCTL variant, in which the altp2m view can be
> transmitted (0 for the default view, or when altp2m is disabled).
> The xen-access test has been updated in the process.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>

I am sorry to be awkward here, but as this patch stands, it definitely
breaks the original usecase altp2m was introduced for.  Therefore, I
don't it is appropriate to take in this form.

The problem is that the current permissions are too coarse-grained.

Intel's use case needs all hypercalls usable by the guest, as the agent
is entirely in-guest.  (It also occurs to me that scenario might be
useful to develop within.)

Bitdefenders use case needs vmfunc usable by the guest, but all
alteration of view permissions must be restricted to a more privileged
entity.

Tamas' usecase is (IIRC) entirely behind the back of the guest.


As a result, the two choices needed are "can a guest configure/use
vmfunc", and "can a guest alter its own view permissions".

These should cater to all usecases, as far as I understand.

So I have an outstanding patch that addressed this issue, at least partially: https://patchwork.kernel.org/patch/9284861. It was part of a larger series that didn't yet make it to upstream but it doesn't depend on anything in that series so we could take it out. The goal with that patch was to be able to indicate how the default altp2m should behave, ie. mixed internal-external use, or purely external. If there is a need for a third option that would specify that only the #VE call should be enabled from within the guest, that could probably be added.

Tamas

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