| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] MSR related clean up
Keir Fraser wrote:
> On 24/06/2009 10:21, "Sheng Yang" <sheng@xxxxxxxxxxxxxxx> wrote:
>
>> What we suffered now is, there are some MSRs existed in CPU, but
>> shouldn't be accessed by guest. And guest should expected a GP fault
>> for accessing, but we return a real value, which is not desired at
>> all.
>>
>> And in general, reading from unknown native MSR is dangerous, and
>> also break host/guest isolation. I think we at least should control
>> what we read from native. Maybe add more MSR handling is necessary.
>
> I kind of agree with you, up to but not including delivering #GPs
> that would not be delivered when running the guest OS natively. A
> middle ground might be to return all zeros for unknown MSRs for which
> rdmsr_safe() succeeds. That is by far the most popular bodge value we
> manually use to fix up cases where returning the real MSR value was
> actually a proven problem.
>
> -- Keir
Returning 0 solves the security concern. But the argument is still that if the
guest should see same MSR sets with native. The CPUID virtualization provides
close features with native, but still not identical.
An ideal solution for those MSR read should consult guest CPUID and then decide
to either inject #GP if guest CPUID doesn't indicate this MSR, or return a
virtual MSR. In this case MSR write side should provide the virtual MSR too.
BTW, user can identify certain filtering policy or force some bits of guest
CPUID, so current approach can't satisfy both cases.
Eddie
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home