[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.


Thanks,
Razvan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.