Re: Ping²: [PATCH] x86/PV: conditionally avoid raising #GP for early guest MSR accesses

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.02.2021 12:32, Andrew Cooper wrote:
> On 05/02/2021 10:56, Jürgen Groß wrote:
>> On 05.02.21 11:14, Jan Beulich wrote:
>>> On 04.11.2020 11:50, Jan Beulich wrote:
>>>> On 03.11.2020 18:31, Andrew Cooper wrote:
>>>>> We should have the impacted MSRs handled explicitly, with a note
>>>>> stating
>>>>> this was a bug in Linux 4.14 and older.  We already have workaround
>>>>> for
>>>>> similar bugs in Windows, and it also gives us a timeline to eventually
>>>>> removing support for obsolete workarounds, rather than having a
>>>>> "now and
>>>>> in the future, we'll explicitly tolerate broken PV behaviour for
>>>>> one bug
>>>>> back in ancient linux".
>>>>
>>>> Comparing with Windows isn't very helpful; the patch here is
>>>> specifically about PV, and would help other OSes as well in
>>>> case they would have missed setting up exceptions early in
>>>> just the PV-on-Xen case. For the HVM case I'd indeed rather
>>>> see us go the route we've gone for Windows, if need be.
>>>
>>> As can be seen from this reply, we're not in agreement what to
>>> do here. But we need to do something. I'm not sure how to get
>>> unstuck discussions like this one ...
>>>
>>> Besides this suggestion of yours I also continue to have
>>> trouble seeing what good it will do to record an exception to
>>> inject into a guest when we know it didn't install a handler
>>> yet.
>>
>> As we need to consider backports of processor bug mitigations
>> in old guests, too, I think we need to have a "catch-all"
>> fallback.
>>
>> Not being able to run an old updated guest until we add handling
>> for a new MSR isn't a viable option IMO.
> 
> You're trading off against issuing XSAs for all the unknown quantities
> of sensitive in MSRs on all past and future platforms.  This has
> unbounded scope.
> 
> Xen's previous behaviour was astoundingly stupid, and yes - we're
> playing more than a decades worth of catchup in one release cycle.
> 
> I'll absolutely take "care/tweaks need to happen crossing the Xen
> 4.14=>4.15 boundary" over whack-a-mole for MSRs in the form of security
> advisories.

All of this reads as if someone was asking to re-introduce the
blind leaking of MSRs. I'm pretty sure though you realize that
this isn't the case, so I guess I'm confused ...

Note that while I have just disagreed with Jürgen's specific
case, I still think the conclusion is right: Where possible
_without_ reintroducing tjhe bad original behavior, we should
try to not put ourselves in the position of needing to update
Xen once guests want to access new MSRs (or even us simply
being unaware of present guests having rarely used code paths
leading to such MSR accesses).

Jan