Re: [PATCH 5/6] x86/HVM: prefill cache with PDPTEs when possible

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 19/07/18 19:37, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@citrix.com> 07/19/18 1:55 PM >>>
>> On 19/07/18 12:47, Jan Beulich wrote:
>>>>>> On 19.07.18 at 13:15, <andrew.cooper3@citrix.com> wrote:
>>>> On 19/07/18 11:50, Jan Beulich wrote:
>>>>> Since strictly speaking it is incorrect for guest_walk_tables() to read
>>>>> L3 entries during PAE page walks, try to overcome this where possible by
>>>>> pre-loading the values from hardware into the cache. Sadly the
>>>>> information is available in the EPT case only. On the positive side for
>>>>> NPT the spec spells out that L3 entries are actually read on walks, so
>>>>> us reading them is consistent with hardware behavior in that case.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> I'm afraid that this isn't architecturally correct.  It means that an
>>>> emulated memory access will read the PDPTE register values, rather than
>>>> what is actually in RAM.
>>> I'm afraid I don't understand: A CR3 load loads the PDPTEs into
>>> registers, and walks use those registers, not memory. That's the very
>>> difference between PAE and all other walks.
>> Patch 3 causes memory reads to come from the cache.
>>
>> This patch feeds the PDPTE registers into the cache, which breaks the
>> architectural correctness of patch 3, because the PDPTE registers may
>> legitimately be stale WRT the content in memory.
> Exactly. And I want to use the register contents in that case. Hence the filling
> of the cache here from the register values.

But using the register values is wrong here.

>
>
>> The pagewalk reading of top_map doesn't require that top_map points into
>> guest space.  If you read the PDPTE registers onto the stack, and pass a
>> pointer to the stack into the pagewalk in the 3-level case, then you fix
>> the issue described here without breaking patch 3.
> I'm afraid I still don't understand: Why "onto the stack"? And anyway - are
> you trying to tell me this odd is how actual hardware behaves?

Consider the following scenario:

; %eax points at some valid PDPTEs

mov %eax, %cr3 ; Copies 32 bytes into the hidden registers.
mov $0xdead, 8(%eax) ; Clobbers PDPTE[1].  Hardware register still intact.
FEP mov 8(%eax), %ebx ; Reads the memory behind the clobbered PDPTE[1]

When emulating the 3rd instruction, you actually need to read memory,
not the cached PDPTEs, because the value can be different.  Therefore,
you must not put the PDPTEs into the cache in the first place, because
it will cause erroneous behaviour.

My point with the top_map pointer is that you can arrange for it to
point to the real PDPTEs (pulled out of the VMCS) rather than reading
the real guest RAM at the physical address pointed to by %cr3.

~Andrew

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