>>> On 22.02.18 at 15:53, <andrew.coop...@citrix.com> wrote:
> On 22/02/18 13:44, Jan Beulich wrote:
>> ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says
>> that the function returns 0 for unrecognized MSRs, so
>> {svm,vmx}_msr_write_intercept() should not convert this into success.
>> At the time it went in, commit 013e34f5a6 ("x86: handle paged gfn in
>> wrmsr_hypervisor_regs") was probably okay, since prior to that the
>> return value wasn't checked at all. But that's not how we want things
>> to be handled nowadays.
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> I agree in principle, but this does have a large potential risk for
> guests.  Any unknown MSR which guests don't check for #GP faults from
> will now cause the guests to crash.
> That said, it is the correct direction to go long-term, and we've got to
> throw the switch some time, but I expect this will cause problems in the
> short term, especially for migrated-in guests.

Thinking about this again, the RDMSR side of things already raises
#GP for inaccessible MSRs. We obviously can't do a probing WRMSR
in {svm,vmx}_msr_write_intercept(), but couldn't we rdmsr_safe()
in the "case 0:" block, treating the result as the verdict whether to
raise #GP to the guest? As the read path does this anyway, we're
not exposing ourselves to new risks.


Xen-devel mailing list

Reply via email to