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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Nov 27, 2018 at 12:31:35PM +0200, Razvan Cojocaru 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.
> > 
> > How could the event for P1 be lost? If the instruction writes to both
> > P1 and P2, you already got some kind of event since writing to P1
> > would trigger a fault. Then you can just discard the P2 part, forward
> > the P1 access and just emulate the instruction?
> 
> Sorry for the late reply, I'm not in the office and have spotty access
> to a real computer.
> 
> The instruction will write to P1, and running it will trigger a page
> walk that writes into P2 (where both P1 and P2 are write-protected).
> 
> The Xen emulator currently _completely_ ignores EPT restrictions, which
> is both the reason why we're able to use it for introspection purposes
> (so we can run instructions that write to protected pages that we've
> deemed to be safe, without lifting said restrictions), and the problem
> in this case.
> 
> So emulating the instruction we're talking about will silently write
> both P1 and P2, even though we'd like the write to P2 (the page walk
> part) to succeed, but still have the vm_event for P1.

Would it be possible to add some kind of flag to the emulator to
signal whether p2m restrictions should be enforced/ignored?
hvmemul_acquire_page seems like a suitable place, but I'm not that
familiar with the emulator.

Then you could generate vm events from the emulator itself, which
AFAICT is the only way to handle this instruction execution issue.

> >> 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.
> > 
> > Can't you just change the p2m of a single vCPU? Either using altp2m or
> > some other mechanism.
> 
> As Jan has pointed out, we'd need too many altp2ms (there's currently a
> hardcoded limit of 10 in Xen). But even more importantly, perhaps, is
> that altp2m is not usable at all at the moment (at least until the
> series I've been working on with George's kind help goes in) - because
> the guests' displays freeze when switching to a new altp2m early on
> boot, or after a screen resize.
> 
> Also, not all Intel hardware supports altp2m, and while Xen does emulate
> altp2m support for hardware that does not, it's not ideal to use that
> performance-wise.

IMO, the best way is move forward with this issue is to enhance the
emulator to be able to generate vm events.

Thanks, Roger.

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