[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/2][4.15] x86/PV: conditionally avoid raising #GP for early guest MSR reads


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 12 Mar 2021 11:19:12 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dTYqEk3VcqDeq2SWk/2UwSmLiF8lTBLnOqOhkCxoKCk=; b=iaCOx8afvNaJlEBcUo5xXxsWstJyK4rZhyLjDsEdYt0yjX/Q0upSH75cmX5h/ASeYP0mJ4RnLzoyO4eR9dXrAI8d9qM/YnEcEiT0H9yUIyLSMVT4tpgezzajoyK/3gvGoua1262FlZkyh93S40R1q0vSZ33wT4FXNOiQsrcWZfAUzlp2lalS1hw8zwljZbdB6mWqWE5DYb6+IY7DCbzIL7eYnpZ6jMbWA+s8FuuA99NvKPvGPulF1SHTBbeuyX3hpItJVFXwWbyX8QVXWNDObCE7cv/0KqiEEAF0LlKFmhsxZ2vk5eh4pq9BQDHs9X/0ktis8+5hqUpuEKQDb1kP1w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AFZKjlWB62NLb1MMQ8cuC1M47I9WTgPxkZ9UspxRvFsBsNgAk8ZMF81mZohjBXly16TCfFZFNWNpKWd5RdNUXsLQDbKWzurRhyQn+ChwnQw0EpW5zx6wovDvAUAlB55e6qwsE54/IYtRomR4oA+bvdJ0vrq91uxBaxrQAWz/vU0prSjYSb3pGt8IXS5jHQTHdAgVCqp7Ek0Bl3g1vfy1PR27wYsavMQ/iCIxEydRk13z2o4HdBPia7FrEHgdFPGuwA8zaDSMgrXaFKcybjra5R0IvNUT8qyzlXuGWrzKTHMmEZZ1hP/lTqTaIr+dplb5BTcfEJTV0GJHxUOKbaWB5A==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Fri, 12 Mar 2021 11:19:27 +0000
  • Ironport-hdrordr: A9a23:GdfvGqpZq+gYGF5Uk6jmpzsaV5uEKtV00zAX/kB9WHVpW+SivY SHgOkb2RjoiDwYRXEnnpS6NLOdRG7HnKQa3aA4Bp3neAX9omOnIMVZ7YXkyyD9ACGWzIFg/I 9aWexFBNX0ZGIXse/T/BS4H9E8wNOO7aCvgqPkw21wSBxxApsB0y5SIG+gYylLbSNBAoc0E4 fZw8JBqSapd3h/VLXEOlAuWe/fq9rX0K/8aRkdCBI9rCWIhzWk6Ln1eiLooSs2eTVJ3Lsk7C z5gxX0j5/Tz82T5z398yvo75pQkMb80dcrPq2xo+UcNzmEsHfSWK1PQLuH1QpFxt2HyFFvq9 XUpgdlAsIb0QKtQkiQgT/Anzbtyywv7XiK8y7rvVLGrdbiTDw3T+pt7LgpCifx0EYrsNFi3K 8j5Qvw3PA7fHCw/lWI2/HyWx5njUayq3Y5+NRj6EB3aocCdKRX6bUW4UI9KuZyIAvB9IslHO NyZfusncp+TFXyVQG9gkBS2tC2Glw8EhCaK3JywPC94nx9mXB0yFYg38oPnnsM34JVceg128 30dotvj71AVckQcOZUA/oAW9K+Dij3TQvLK3/6GyWoKIg3f1b277Ln6rQ84++nPLQO0ZsJgZ zEFHdVr3Q7dU7CAdCHtac7syzlcSGYZ3DA28te7592tvnXX7zwKxCOT1gojo+Jv+gfKtezYY fwBLtmR9vYaUf+E4dA2APzH7NIL2MFbcETstEnH3qTv8PwLJHwvOCzSoeRGJPdVRIfHk/vCH oKWzb+YO9a6FqwZ3P+iB/NH1z3fEjS+o9xDbj68+AfxJNlDPwJjiElzXCCou2bIzxLtaI7OG FkJqn8r6+9rW6quUbEhl8ZfSZ1PwJw2vHNQnlKrQgFPwffarAYoeiSfmhUwT+iLh97RMXGLR 5Hqz1MiOSKBq3V4RpnJ8OsM2qcgXdWjmmNVY0glqqK4tqgXZ8kEJA8WuhUGR/QHxJ43SZmwV 0zKDMsdwv6LHfDmK+lhJsbCKX0bN9nmjqmJsZStDb4rkWTpcYmQ1MBRD6wWcurgQIjLgAkw2 FZwus6uv6tiDyvIWwwjKATK1tXclmaB7pAEUC4folOo6vqfwtxVG+OojSfh3gICzPX3nRXol akATyfePnNDFYYnnxDyK7l/Gl5cXinc1tqZmp3tpB8Emr6qm9+uNX7E5ab4i+0UB8v0+sdOD bKbX8pLgRiy8ue+TSVlDyBfE9Wi6kGD6j4NvAOYrvT0nSiJMm0jqkABeZT54sgHsvpqPU3Xe WWfBK1IDv0B/gy4RGcom8oNUBP2SEZuMKt/CegwHmz3XY5D/aXHU9vQKsDJcqAq0fjXPSF3f xC/JoIlNr1Fl+0TNGIyavaNWEebjzSpHO7VOEup9R/u7kouL56ApncVn/p2Rh8rWMDBfaxsH lbZqJxpI3lEMtIWec5fipC5FonlNiVNiIQw0bLK957WWtotmPROtOC3qHBprUuCHCQvQeYAy jpzwRtu9P+GxaZ3bEUC6gMMX1bRUg15nNl5v6DfeTreUyXXtAG2FqxKXmmdrBBDICDBLULtx 5/iuv409O/Rm7d2ArKuyF8Lb8L22G7QdmqCAbJPeJT6dS1NRCthaStifTDwwvfeH+ea04Cg5 dCelFVRsNfiiM6hIly6xOMcMXM0wkYumobxypmmF7r0pWn52mePXguC3ypvrxmGR9JMnaJis zZ9/O/z3qV2kkf5aX+
  • Ironport-sdr: 4+NG2FJo25fSEZkfJPvmwi5mBcct4zYoYhUQe3L2f+ZXjVC2b5JIt2AhgEFbFQAN+I6yn3l7UM uBljtcOqYQLUFjHaC1tZ4kP1E8wraQTGcXTDNFP6LsdwVBp3rWl29pWO3G6dFdgxymZfdWRRL0 JvRDv+ldeTHUvFxzDYkkPvqULyWsX3riTSe8or+LLoJVZsLghGFb3WajetrCnE1KZ5DWvcwy+o Ao8rolI6JOGXQC1I9wn+9UpT9waxfl24dv/IqrGo2RXW6++xPOYwiOqEPMWZf8gcREj5jArgHP AoE=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12/03/2021 07:54, Jan Beulich wrote:
> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
> handler early enough to cover for example the rdmsrl_safe() of
> MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
> of MSR_K7_HWCR later in the same function). The respective change
> (42b3a4cb5609 "x86/xen: Support early interrupts in xen pv guests") was
> backported to 4.14, but no further - presumably since it wasn't really
> easy because of other dependencies.
>
> Therefore, to prevent our change in the handling of guest MSR accesses
> to render PV Linux 4.13 and older unusable on at least AMD systems, make
> the raising of #GP on this paths conditional upon the guest having
> installed a handler, provided of course the MSR can be read in the first
> place (we would have raised #GP in that case even before). Producing
> zero for reads isn't necessarily correct and may trip code trying to
> detect presence of MSRs early, but since such detection logic won't work
> without a #GP handler anyway, this ought to be a fair workaround.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Release-Acked-by: Ian Jackson <iwj@xxxxxxxxxxxxxx>

I am still of the firm belief that this is the wrong course of action.

It is deliberately papering over error handling bugs which, in the
NetBSD case, literally created memory corruption scenarios.  (Yes - that
was a WRMSR not RDMSR, but the general point still stands, particularly
in light of your expectation to do the same to the WRMSR).

It is one thing to not realise that we have a trainwreck here.  Its
totally another to take wilful action to keep current and all future
guests broken in the same way.

The *only* case where it is acceptable to skip error handling is if the
VM admin has specifically signed their life away to say that they'll
accept the, now discovered, potential-memory-corrupion consequences.

Rogers patch already does this.

~Andrew




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.