Re: [Xen-devel] [PATCH RFC v2 2/2] x86/emulate: Send vm_event from emulate

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Fri, Jan 11, 2019 at 2:37 PM Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> On 1/11/19 10:51 PM, Tamas K Lengyel wrote:
> > On Fri, Jan 11, 2019 at 9:51 AM Razvan Cojocaru
> > <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> >>
> >> On 1/11/19 6:38 PM, Tamas K Lengyel wrote:
> >>> On Fri, Jan 11, 2019 at 8:37 AM Alexandru Stefan ISAILA
> >>> <aisaila@xxxxxxxxxxxxxxx> wrote:
> >>>>
> >>>> This patch aims to have mem access vm events sent from the emulator.
> >>>> This is useful in the case of page-walks that have to emulate
> >>>> instructions in access denied pages.
> >>>>
> >>>
> >>> I'm a little confused about the scenario you mention here. You mark
> >>> pages where the pagetables are non-readable/writable in EPT and you
> >>> expect the emulated instruction would also violate access permissions
> >>> of the guest pagetable itself?
> >>
> >> Hello Tamas,
> >>
> >> The scenario is this: the pagetables are read-only. At some point, a
> >> walk tries to write the accessed bit, or the dirty bit somewhere in that
> >> read-only memory, causing an EPT fault, so we end up in
> >> p2m_mem_access_check().
> >>
> >> Understandably, we don't care about sending this event out to the
> >> introspection application (we could if we wanted to, which is why this
> >> behaviour is configurable, but I think it's safe to say that for most
> >> introspection use-cases this is something we don't care about, and hence
> >> a perfect opportunity for optimization).
> >>
> >> Now, emulating the current instruction helps, and it works. But, what if
> >> that instruction would have tried to write to another protected page?
> >> Emulating it, as things stand now, means that we will lose _that_ event,
> >> and that's potentially a very important EPT event.
> >>
> >> We've tried to attack this problem by only writing the A/D bits and
> >> almost came to a satisfactory solution but there's still some debate on
> >> whether it's architecturally correct or not - that approach needs more
> >> studying.
> >>
> >> The alternative we've come up with is to instead, at least for the time
> >> being, attempt to send out vm_events from the emulator code only in this
> >> case: where we want to emulate the page walk without consulting the EPT,
> >> but want to consult it when actually emulating the current instruction.
> >>
> >> I hope that made sense.
> >
> > I'm still confused :) In the pagetable walking case, didn't the
> > instruction you are emulating just trip by writing to a page you want
> > to allow it writing to (the A/D bits)? Or are you saying there is an
> > unrelated trap happening with an execute-violation but you don't know
> > what other write-protected page it would have tripped if it actually
> > executed, and by emulating you effectively miss that write event? The
> > latter makes sense, it's the pagetable walking case I have a hard time
> > putting together.
>
> OK, assume we have instruction I that accesses page X, which access in
> turn causes the A/D bits to be set in pagetable page Y (because it
> triggers a page walk). We want to allow the write to Y (setting whatever
> A/D bits), but if X is write-protected and I tries to write into it, we
> want a vm_event for that write.
>
> With the current code, if we emulate I to write to Y, we lose a
> potential vm_event for the write to X. This doesn't happen often, but it
> does happen.

Ah, got it. Thanks, makes sense.

Tamas

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