On 17/12/2020 16:25, boris.ostrov...@oracle.com wrote: > On 12/17/20 2:40 AM, Jan Beulich wrote: >> On 17.12.2020 02:51, boris.ostrov...@oracle.com wrote: >> I think this is acceptable as a workaround, albeit we may want to >> consider further restricting this (at least on staging), like e.g. >> requiring a guest config setting to enable the workaround. > > Maybe, but then someone migrating from a stable release to 4.15 will have to > modify guest configuration. > > >> But >> maybe this will need to be part of the MSR policy for the domain >> instead, down the road. We'll definitely want Andrew's view here. >> >> Speaking of staging - before applying anything to the stable >> branches, I think we want to have this addressed on the main >> branch. I can't see how Solaris would work there. > > Indeed it won't. I'll need to do that as well (I misinterpreted the statement > in the XSA about only 4.14- being vulnerable)
It's hopefully obvious now why we suddenly finished the "lets turn all unknown MSRs to #GP" work at the point that we did (after dithering on the point for several years). To put it bluntly, default MSR readability was not a clever decision at all. There is a large risk that there is a similar vulnerability elsewhere, given how poorly documented the MSRs are (and one contemporary CPU I've got the manual open for has more than 6000 *documented* MSRs). We did debate for a while whether the readability of the PPIN MSRs was a vulnerability or not, before eventually deciding not. Irrespective of what we do to fix this in Xen, has anyone fixed Solaris yet? ~Andrew
