Re: [Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.10.2019 12:43, Andrew Cooper wrote:
> On 30/10/2019 10:39, Jan Beulich wrote:
>> To fulfill the "protected" in its name, don't let the real hardware
>> values "shine through". Report a control register value expressing this.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> TBD: Do we want to permit Dom0 access?
> 
> I would recommend reordering the two patches and putting this one first
> (along with the enumeration details, along with a pair of feature
> strings in xen-cpuid).  This patch at least wants backporting.

Well, the reason for this ordering is because this way Dom0
doesn't transiently lose all access.

As to xen-cpuid - I admit I simply forgot to update it, largely
due to there not being any CPUID bit on the Intel side. That part
would obviously live in whichever patch we elect to be first.

> This would be far more simple if we don't permit dom0 access.  Yes, it
> shares platform responsibility with Xen, but it also can't do anything
> more with the value than Xen can, which is to simply print it out for #MCEs.

Okay, then let's not expose it. I'll drop the TBD.

> Avoiding giving dom0 access would remove the need to attempt to
> virtualise something which is model specific on the Intel side, and
> allow all 4 MSRs to be unconditional #GP's.  I for one don't want to
> have to consider the migration implications of letting guests see this.

I don't understand the connection between Dom0 access and possible
migration implications. I'm also struggling to see how, for a well
behaved guest, there would need to be any migration considerations
in the first place: Once it has read the control register and found
the lockout bit set, it shouldn't make any further access attempts.
Similarly once it got a #GP(0) upon access, it wouldn't try again.
There would be an issue only if we actually supplied PPIN values,
even if it were just fake ones.

Jan

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