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

From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "kevin.tian@intel.com" <kevin.tian@intel.com>,
	"tamas@tklengyel.com" <tamas@tklengyel.com>,
	"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"Mihai Donțu" <mdontu@bitdefender.com>,
	"Andrei Vlad LUTAS" <vlutas@bitdefender.com>,
	"jun.nakajima@intel.com" <jun.nakajima@intel.com>,
	"Alexandru Stefan ISAILA" <aisaila@bitdefender.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults
Date: Tue, 27 Nov 2018 12:31:35 +0200	[thread overview]
Message-ID: <67fa7dc6-3aff-a5fd-4105-dce19a89448c@bitdefender.com> (raw)
In-Reply-To: <20181123085402.663pdh75rhqtxsf4@mac>

>> _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.

>> 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.

Thanks,
Razvan

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