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

Re: [PATCH][4.15] x86: mirror compat argument translation area for 32-bit PV


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 22 Feb 2021 20:36:24 +0100
  • 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=3MEpMaYpx1LTAi9LKxCvjT5JulrsbKJ6fs0Biqt+3zM=; b=eJWKIQ+YU1sSAxISRR0lbN9iscF5WytJn9owYp8zURYBhsrFPfTZM+pIrU1f88hx3usBnxlp5foefh/+5196j7Fr8s7OnDDHo1S+wVLrqVIflf3XYO9GgF/BeY5Fhjk0CtbYeNufUwCbs6jTawM5A18ETgTQRIW7RN0ljYqMQGxrIi4LCFPuJGVGSNDpp+oR2Nt06jXVGtARz3iRKkiQ1dKyHR0r/KCSGNAUURBMrzOXuo5qwlDPYRivsdMiuvKfFxAtl5yog3mXtqHnXKKrTW0zL+R5CQvzELQweNBaUvs1XR693tAe5ETDNQVbMUeh+Y/ER+eldxQPmtikFJV+pQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XKfzNeEIbuyTj1FINJDtvSsVqfww5QEqe5m0ZOoFtL3RUpPm1u4VXB+TyftBbZBcl0uoZu5Qjd/6n4ZF5EpZumY3apkCE2ldgodU6YjQOwdv544FQT1Rh7lkYB7u8ffYdP75PwTwheIuNvmIVHYRJ1yl+ETsrnCadWb+4VZO/Xub6vI49hcd/v1HWPBiKKDscm1SFlkkNNpKSI+ahBie8rlZ8Vl70a5/E6fcYnEcnQ8MO8urL4rxEmwA6+mYR1kjukf2zNQ8ggTHhdLbCuIuTJgO+JkLcXwezlnMYxIcJvpcg7BRfjaaOEfplEkQNjPgHknmujvCdkxrtMmint+QXg==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 22 Feb 2021 19:36:45 +0000
  • Ironport-sdr: jUvTIvZWIdATa/pn29vU+7/MGA94YGdjfMotrAJIYmrEBpoSQqVIhCKRaKKSVfnd+wGETA4R1M II3kAn5kuk0QkyA3tGHBa7t2kIKeFhFmp38VPepmjoRPWVoEB75QJ+ytUb/g/czL1v5piiPml/ r2Hn0rFt3P6iIdp6IukB8e7SZcvmYKXt/30E/wcADnhqWuJdJ62TYbmHH9dg+lDz3mpH/poz00 ZCTDvGNkz8c/qXRuE0gx5I0xvMP9bRZXyirUgpFANirxWA/0eZDp1n1AWLDbax//UwyLyV6Ckl 8u0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Feb 22, 2021 at 04:47:38PM +0000, Andrew Cooper wrote:
> On 22/02/2021 14:22, Jan Beulich wrote:
> > On 22.02.2021 15:14, Andrew Cooper wrote:
> >> On 22/02/2021 10:27, Jan Beulich wrote:
> >>> Now that we guard the entire Xen VA space against speculative abuse
> >>> through hypervisor accesses to guest memory, the argument translation
> >>> area's VA also needs to live outside this range, at least for 32-bit PV
> >>> guests. To avoid extra is_hvm_*() conditionals, use the alternative VA
> >>> uniformly.
> >>>
> >>> While this could be conditionalized upon CONFIG_PV32 &&
> >>> CONFIG_SPECULATIVE_HARDEN_GUEST_ACCESS, omitting such extra conditionals
> >>> keeps the code more legible imo.
> >>>
> >>> Fixes: 4dc181599142 ("x86/PV: harden guest memory accesses against 
> >>> speculative abuse")
> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >>>
> >>> --- a/xen/arch/x86/mm.c
> >>> +++ b/xen/arch/x86/mm.c
> >>> @@ -1727,6 +1727,11 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
> >>>                 (ROOT_PAGETABLE_FIRST_XEN_SLOT + slots -
> >>>                  l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t));
> >>>      }
> >>> +
> >>> +    /* Slot 511: Per-domain mappings mirror. */
> >>> +    if ( !is_pv_64bit_domain(d) )
> >>> +        l4t[l4_table_offset(PERDOMAIN2_VIRT_START)] =
> >>> +            l4e_from_page(d->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
> >> This virtual address is inside the extended directmap.
> > No. That one covers only the range excluding the last L4 slot.
> >
> >>   You're going to
> >> need to rearrange more things than just this, to make it safe.
> > I specifically picked that entry because I don't think further
> > arrangements are needed.
> 
> map_domain_page() will blindly hand this virtual address if an
> appropriate mfn is passed, because there are no suitability checks.
> 
> The error handling isn't great, but at least any attempt to use that
> pointer would fault, which is now no longer the case.

AFAICT map_domain_page will never populate the error page virtual
address, as the slot end (MAPCACHE_VIRT_END) is way lower than
-MAX_ERRNO?

We could add:

BUILD_BUG_ON((PERDOMAIN_VIRT_SLOT(PERDOMAIN_SLOTS) - 1) >= (unsigned 
long)-MAX_ERRNO);

For safety somewhere.

Roger.



 


Rackspace

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