[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: refine debugging of SMEP/SMAP fix



>>> On 17.05.16 at 14:56, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 17/05/16 11:42, Jan Beulich wrote:
>>>>> On 17.05.16 at 12:28, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 17/05/16 10:54, Jan Beulich wrote:
>>>> Instead of just latching cr4_pv32_mask into %rdx, correct the found
>>>> wrong value in %cr4 (to avoid triggering another BUG). The value left
>>>> in %rdx should be sufficient for deducing cr4_pv32_mask from the
>>>> register dump.
>>> Alternatively, you can reuse %rax (as its value is useless by this
>>> point) and leave %rdx as exactly cr4_pv32_mask.  This avoids needing a
>>> subsequent step to reverse engineer cr4_pv32_mask.
>> I don't view the value in %rax as useless - that's the set of bits
>> we have found set, which didn't match our expectation. Hence I
>> specifically don't want to re-use that register.
> 
> Ok.  We don't need to preserve any registers from the caller, so using a
> different one such as %rbx or %rcx would be fine.

Well, I can certainly (yet hesitantly) do that (and I see no harm in
clobbering another register), but ...

> The issue is that it is important to see precisely what cr4_pv32_mask is.

... it's not really clear to me what case you see where the value
just written to CR4 won't give you all the information you need.
After all cr4_pv32_mask doesn't have an awful lot of possible
values.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.