On 27/08/18 15:08, Jan Beulich wrote: >>>> On 27.08.18 at 15:47, <rcojoc...@bitdefender.com> wrote: >> On 8/27/18 4:17 PM, Jan Beulich wrote: >>>>>> On 27.08.18 at 15:02, <andrew.coop...@citrix.com> wrote: >>>> This should be architecturally correct as it is exclusively derived from >>>> information provided by the VMExit, and won't cause dirty bits to be >>>> written in cases where the hardware wouldn't have written them >>>> (speculative or otherwise). It does mean that an instruction which >>>> would need to set A and D bits in the walk will take two EPT violations >>>> to achieve the end result, but it probably is still quicker than sending >>>> the vm_event out. >>> I'm afraid this is going to be only mostly correct: Atomicity of the page >>> table write is going to be lost. This could become an actual problem if >>> the guest used racing PTE accesses. Such racing accesses might not >>> be a bug - simply consider the OS scanning for set A and/or D bits >>> (and clearing them when they're set). Or an entity temporarily clearing >>> (parts of) PTEs, with recovery logic in place to restore them when >>> needed for a synchronous access. At the very least there's then the >>> risk of a live lock within the guest. >> But it's not clear to me why that can't already happen when just >> emulating the current instruction (as we do now), if emulating said >> instruction would set A or D? > Yes, good point - this is a problem not just to the new handling you > propose.
There is no risk of livelock. The A/D bits we get an EPT-violation on are those which are write protected, so any modification at all will trap. In particular, an attempt from software to play in weird ways with the pagetable will cause real vm_events which will be sent for auditing. Legitimate updates (e.g. the guest paging-out algorithm refreshing its A/D metadata) will be permitted, whereas illegitimate ones will trigger remediation. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
