Re: [Xen-devel] [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.11.18 at 19:24, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> _However_, please picture an instruction that both writes into a page P1
> we're interested in, _and_ causes a write into a read-only page-walk
> related page P2. Emulating the current instruction, as the upstream
> patch does, does eliminate the vm_event caused by writing into P2, but
> with the unfortunate side-effect of losing a potentially critical event
> for the write into P1.
> 
> What this patch attempts to do is to mark P1 rwx (so allow the write),
> then put the faulting VCPU into singlestep mode, then restore the
> restrictions after it has finished single stepping. By now it's obvious
> why all the other VCPUs need to be paused: one of them might do a
> malicious write into P1 that silently succeeds (since the EPT is shared
> among all VCPUs - putting altp2m aside for a moment). We don't want that.

I think this all goes into the fundamentally wrong direction. If lost
events during emulation are your issue, then let's make sure
emulation paths trigger the same events hardware would.

With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progress. As before,
if there are particular instructions you know of that the emulator
doesn't handle yet, please keep pointing these out. Last I know
were some AVX move instructions, which have long been
implemented.

> Alternatively, we'd be happy with simply being able to set the relevant
> A/D bits in the pages touched by the page walk, but after lenghty
> negotiations that can be found in the xen-devel archives we were unable
> to find a safe, architecturally correct way of doing that.

Hmm, I don't recall that we had settled that this would be entirely
impossible, but then again - as per above - this as well was only
curing symptoms rather than the cause.

Jan



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