|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.
On Tue, Aug 2, 2016 at 10:40 AM, Julien Grall <julien.grall@xxxxxxx> wrote: > > > 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? Yes, that's correct. I can tell you my use-case for it. I'm using breakpoints to trace the execution of the kernel by writing 0xCC to function entry points and configure the VMCS to trap to the VMM when such instructions execute. Now, the kernel can detect that these instruction are written to it's memory and for example Windows would blue-screen. So, to avoid that, I create a shadow copy of the page and only add breakpoints there. Then create an altp2m view and use gfn remapping to point the gfn to this new mfn. This view is execute only, thus when the kernel tries to read, we can switch back to view 0 where it just sees it's original page without breakpoints. At this point the shadow copy is also in the guest_physmap so a malicious kernel could just scan the physical memory and search for such shadow copies. Thus to avoid the detection I also have an empty page added to the physmap. In both the default view and the execute view all shadow copy pages are marked non-readable using their actual gfn. By creating another, third view, we remap all shadow copy pages to the empty page. This way, if the kernel is trying to read the contents of the shadow copy pages with their actual gfn's we can switch to this third view and the kernel will only see a blank page. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |