Re: [Xen-devel] More questions about Xen memory layout/usage, access to guest memory

[Tamas K Lengyel <tamas.k.lengyel@gmail.com>]

On Thu, Aug 22, 2019 at 6:03 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 23/08/2019 00:06, Tamas K Lengyel wrote:
> > On Thu, Aug 22, 2019 at 4:40 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >> On 22/08/2019 21:57, Rich Persaud wrote:
> >>>> On Aug 22, 2019, at 09:51, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>>>
> >>>>> On 22/08/2019 03:06, Johnson, Ethan wrote:
> >>>>>
> >>>>> For HVM, obviously anything that can't be virtualized natively by the
> >>>>> hardware needs to be emulated by Xen/QEMU (since the guest kernel isn't
> >>>>> expected to be cooperative to issue PV hypercalls instead); but I would
> >>>>> expect emulation to be limited to the relatively small subset of the ISA
> >>>>> that VMX/SVM can't natively virtualize. Yet I see that x86_emulate.c
> >>>>> supports emulating just about everything. Under what circumstances does
> >>>>> Xen actually need to put all that emulation code to use?
> >>>> Introspection, as I said earlier, which is potentially any instruction.
> >>> Could introspection-specific emulation code be disabled via KConfig?
> >> Not really.
> >>
> >> At the point something has trapped for emulation, we must complete it in
> >> a manner consistent with the x86 architecture, or the guest will crash.
> >>
> >> If you don't want emulation from introspection, don't start
> >> introspecting in the first place, at which point guest actions won't
> >> trap in the first place.
> > That's incorrect, you can absolutely do introspection with vm_events
> > and NOT emulate anything. You can have altp2m in place with different
> > memory permissions set in different views and switch between the views
> > with MTF enabled to allow the system to continue executing. This does
> > not require emulation of anything. I would be behind a KCONFIG option
> > that turns off parts of the emulator that are only used by a subset of
> > introspection usecases. But this should not be an option that turns
> > off introspection itself, the two things are NOT inter-dependent.
>
> I fear we are getting slightly off track here, but I'll bite...
>
> Introspection is a young technology, with vast potential.  This is great
> - it means there is a lot of novel R&D going into it.  It doesn't mean
> that all aspects of it are viable for use by customers today.
>
> I'll have an easier time believing that altp2m is close to being
> production ready when I no longer fine security-relevant bugs in it
> every time I go looking, and someone has made a coherent attempt to
> justify it being security supported.

I didn't say altp2m is security supported or that it's "production
ready", only that it's a viable alternative to using the emulator.
With the external-only mode I added I don't see any additional attack
surface as compared to regular use of EPT, but of course I would be
very interested in the security bugs you seem to be finding left and
right. In my experience it's the emulator that's buggy (or simply
incomplete).

>
> None of this alters the fact that introspection in general is one key
> factor as to why we have a mostly-complete x86_emulate() (even if "x86
> emulate" is a slightly poor choice of name.  "decode and replay" would
> be a far more apt description of what it does for the majority of
> instructions.)

Which is fine, but if people find the presence of a full x86 emulator
troubling and want to disable as much of it as possible, saying that
it's needed for introspection is incorrect. It is not needed for
introspection. So I'm not OK with using that justification for keeping
it. Nor would I like to see an option that says that if you are doing
introspection you _must_ have that full emulator in place. You simply
don't.

Tamas

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