[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |