Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall <julien.grall@xxxxxxx>]

On 02/08/16 17:05, George Dunlap wrote:
> On 02/08/16 16:48, Tamas K Lengyel wrote:
> > On Tue, Aug 2, 2016 at 5:17 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> > > On 02/08/16 08:38, Julien Grall wrote:
> > > > Hello Tamas,
> > > >
> > > > On 01/08/2016 21:41, Tamas K Lengyel wrote:
> > > > > On Mon, Aug 1, 2016 at 1:55 PM, Julien Grall <julien.grall@xxxxxxx>
> > > > > wrote:
> > > > > > > we did discuss whether altp2m on ARM should be exposed to guests or
> > > > > > > not but we did not agree whether restricting it on ARM is absolutely
> > > > > > > necessary. Altp2m was designed even on the x86 to be accessible from
> > > > > > > within the guest on all systems irrespective of actual hardware
> > > > > > > support for it.  Thus, this design fits ARM as well where there is no
> > > > > > > dedicated hardware support, from the altp2m perspective there is no
> > > > > > > difference.
> > > > > >
> > > > > > Really? I looked at the design document [1] which is Intel focus.
> > > > > > Similar
> > > > > > think to the code (see p2m_flush_altp2m in arch/x86/mm/p2m.c).
> > > > > That design cover letter mentions specifically "Both VMFUNC and #VE
> > > > > are designed such that a VMM can emulate them on legacy CPUs". While
> > > > > they certainly had only Intel hardware in-mind, the software route can
> > > > > also be taken on ARM as well. As our primary use-case is purely
> > > > > external use of altp2m we have not implemented the bits that enable
> > > > > the injection of mem_access faults into the guest (equivalent of #VE).
> > > > > Whether without that the altp2m switching from within the guest make
> > > > > sense or not is beyond the scope of this series but as it could
> > > > > technically be implemented in the future, I don't see a reason to
> > > > > disable that possibility right away.
> > > > The question here, is how a guest could take advantage to access to
> > > > altp2m on ARM today? Whilst on x86 a guest could be notified about
> > > > memaccess change, this is not yet the case on ARM.
> > > >
> > > > So, from my understanding, exposing this feature to a guest is like
> > > > exposing a no-op with side effects. We should avoid to expose feature to
> > > > the guest until there is a real usage and the guest could do something
> > > > useful with it.
> > > It seems like having guest altp2m support without the equivalent of a
> > > #VE does seem pretty useless.  Would you disagree with this assessment,
> > > Tamas?
> > >
> > > Every interface we expose to the guest increases the surface of attack;
> > > so it seems like until there is a usecase for guest altp2m, we should
> > > probably disable it.
> > Hi George,
> > I disagree. On x86 using VMFUNC EPTP switching is not bound to #VE in
> > any way. The two can certainly benefit from being used together but
> > there is no enforced interdependence between the two. It is certainly
> > possible to derive a use-case for just having the altp2m switch
> > operations available to the guest. For example, I could imagine the
> > gfn remapping be used to protect kernel memory areas against
> > information disclosure by only switching to the accessible mapping
> > when certain conditions are met.
> That's true -- I suppose gfn remapping is something that would be useful
> even without #VE.
>
> > As our usecase is purely external implementing the emulated #VE at
> > this time has been deemed out-of-scope but it could be certainly
> > implemented for ARM as well. Now that I'm thinking about it it might
> > actually not be necessary to implement the #VE at all the way x86 does
> > by injecting an interrupt as we might just be able to allow the domain
> > to enable the existing mem_access ring directly.
> That would be a possibility, but before that could be considered a
> feature we'd need someone to go through and make sure that this
> self-mem_access funcitonality worked properly.  (And I take it at the
> moment that's not work you're volunteering to do.)
>
> But the gfn remapping is something that could be used immediately.
I looked at the implementation of gfn remapping and I am a bit confused.
From my understanding of the code, the same MFN could be mapped twice 
in the altp2m. Is that right? May I ask the purpose of this?
So if the guest is removing the mapping from the host p2m (by calling 
XENMEM_decrease_reservation), only one of the mapping will be removed.
That will leave the other mapping potentially mapped in one of the 
altp2m. However, AFAICT, x86 does take a reference on the page for 
mapping. So this may point to memory that does not belong to the domain 
anymore. Did I miss anything?
After writing the above paragraphs, I noticed that p2m_change_altp2m_gfn 
seem to take care of this use case.
However, the locking is not the same to protect min_remapped_gfn and 
max_remapped_gfn. p2m_altp2m_propagate_change is protecting them by 
taking the altp2m_list_lock whilst p2m_change_altp2m_gfn is using the 
altp2m lock.
Maybe George or Tamas could give more insight here.

BTW, the x86 version of p2m_change_altp2m_gfn (I have not yet looked at 
the ARM one) does not seem to lock the hostp2m. Is it normal?
Regards,

--
Julien Grall

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