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

Re: [XEN PATCH v1 1/1] x86/domctl: add gva_to_gfn command


  • To: Ковалёв Сергей <valor@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 20 Mar 2023 19:07:32 +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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NWkE4U5R8b9rVxOOkuBEXz2iY0fCUUxNYMZ0IKqmnLk=; b=ajF82OX6oDAA2koYZK9G0v0Oz8KYXmNNBXzWXo9scEe4N4Ymm/9KhtC7nAqAXR/bF5AgimLIIPKKNSVeyisFbZzCIvz+Coput3IagdKUHuqG9rPSIJduG67zMOkQ4kyaqzkvPY2/47fvY0wh71v+PD3G8ejFrWDsaX+W7Ffs2nU0Wp0e4lqB/KJGGatsUEzQit4zZralwrvqLda0lOifZVDWLuIUam0YteKfxqKorns6OMdQhDUrmv4ZPXrx7oTLmCkSbuf1tfhz0xh7JP1JNOehv6x/uUU8mX6Gd4F87q6n6pc7+FBftFOF82/QVhMZ2spSCLgMzvqHJ4g9lqAauw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FxeThuUmAGBV8swnvpIPJddL5PyrOpMYvpu84J5q0ii73Eiq6vK+KWQjMb7C5MzomG/SD4s4GvH4yxMF7AnQkkvEzPzqaK0ivQ9NLrI79u2aeCmHROYZ794yO5c3Ss5579GlgZqzNE9+FvPZyIDp77JpKY6cdP8ArixeOLNEZgOjT3JxcGKpekCRahcUjnp+06sSnbyE4y1DuS5AqPqis3nIniUYKfBw3Fr/te98N7UuASsebVmgssq3ZBDY3q0uKwzYZ7rxFwqpVqIEtcmUhfE2puDkikydVFZOicAqehAkQ72LSGhxQBGCCdUbgu6eTGDG2Ld0yXoOG3XTsf4wmA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Dmitry Isaykin <isaikin-dmitry@xxxxxxxxx>
  • Delivery-date: Mon, 20 Mar 2023 19:08:07 +0000
  • Ironport-data: A9a23:KhBzVqv5IFG6euQTeLeKx9ZjOOfnVN1fMUV32f8akzHdYApBsoF/q tZmKW/UbP2PYjShctxxbIXn9BsD6MXQz99gGwJt+Ck0EC8U+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVKiffHg3HVQ+IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4bKj6Fv0gnRkPaoQ5ASEzyFMZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwJCpTbynYgfiM77eSac5jluEtFtbnBdZK0p1g5Wmx4fcOZ7nmGvyPzvgBmTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0osjv60b4C9lt+iHK25mm6xo G7c8nu/KRYdLNGFkhKO8262h/+JliT+MG4XPOTgqqYz2gDMnwT/DjUGcVuUm8u+03W1Wu5hE GUM/DUotIstoRnDot7VGkfQTGS/lgAVX91KO+k78x3L0Le8yxaUAC0IQyBMbPQitdQqXno62 1mRhdTrCDdz9rqPRhq19L2ZsDezMig9NnIZaGkPSg5ty8bniJE+iFTIVNkLOKyoitz4Hxngz jbMqzIx750IltIC3ai/+VHBghqvq4LPQwpz4R/YNkq55wZwf6a5ZIil71fK4PIGJ4GcJnGAp 3EFmMmYqewLDI2XhQScSeMBEaHv/evtDdHHqVtmHp1k/DP0/XemJNlU+Gsnex0vNdsYczj0Z kOVoRlW+JJYIHqta+lwfp61DMMpi6PnELwJS8zpUzaHWbApHCfvwc2kTRT4M7zF+KT0rZwCB A==
  • Ironport-hdrordr: A9a23:OZJXI6jGBvAEh3lnn+vZS8YlTHBQX6l23DAbv31ZSRFFG/FwyP rAoB1L73PJYWgqNU3IwerwQJVpQRvnlaKdkrNhRotKPTOW8FdASbsJ0WKM+UyFJ8STzIBgPO JbAtFD4b7LfBNHZKTBkW6FOu8a5v+p2oGFr8W29QYqcegCUcgJhDuRSDzrdHGeLzM2ZqbRYa Dsg/av0ADQG0j/AP7bOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPof2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFchcsvy5zX8ISdOUmRcXee r30lcd1gNImjDsl1SO0FXQMs/boXQTAjHZuBqlaDDY0LbErXoBerd8bMRiA1Hkwntlhcp71q 1T2WKfqt54MTPs9R6No+TgZlVSjUyzrmMlkekPy1plcaVbRoNwgOUkjQRo+LFpJlOi1Kk3VO NiEoXG6PNfYTqhHgDkl3gqz9q2UnspGBCaBkAEp8yOyjBT2Gt01k0C2aUk7wA9HT0GOuh5Ds n/Q9FVfYt1P7srRLM4AP1ETdq8C2TLTx6JOGWOIU7/HKVCP37WsZb47Lg8+envIfUzvdIPsY WEVEkduX85ekroB8HL1JpX8grVSGH4WTj20MlR65Vwp7W5Trv2Ni+ITkwojqKb0oMiK9yeX+ z2NINdAvflI2erEYFV3xfmU50XMnUaWN19gKdIZ7tPmLO5FmTHjJ2kTB+IHsuQLd8NYBKBPk c+
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20/03/2023 4:32 pm, Ковалёв Сергей wrote:
> gva_to_gfn command used for fast address translation in LibVMI project.
> With such a command it is possible to perform address translation in
> single call instead of series of queries to get every page table.
>
> Thanks to Dmitry Isaykin for involvement.
>
> Signed-off-by: Sergey Kovalev <valor@xxxxxxx>

I fully appreciate why you want this hypercall, and I've said several
times that libvmi wants something better than it has, but...

> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 2118fcad5d..0c9706ea0a 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1364,6 +1364,23 @@ long arch_do_domctl(
>              copyback = true;
>          break;
>
> +    case XEN_DOMCTL_gva_to_gfn:
> +    {
> +        uint64_t ga = domctl->u.gva_to_gfn.addr;
> +        uint64_t cr3 = domctl->u.gva_to_gfn.cr3;
> +        struct vcpu* v = d->vcpu[0];

... this isn't safe if you happen to issue this hypercall too early in a
domain's lifecycle.

If nothing else, you want to do a domain_vcpu() check and return -ENOENT
in the failure case.

More generally, issuing the hypercall under vcpu0 isn't necessarily
correct.  It is common for all vCPUs to have equivalent paging settings,
but e.g. Xen transiently disables CR4.CET and CR0.WP in order to make
self-modifying code changes.

Furthermore, the setting of CR4.{PAE,PSE} determines reserved bits, so
you can't even ignore the access rights and hope that the translation
works out correctly.

Ideally we'd have a pagewalk algorithm which didn't require taking a
vcpu, and instead just took a set of paging configuration, but it is all
chronically entangled right now.

I think, at a minimum, you need to take a vcpu_id as an input, but I
suspect to make this a usable API you want an altp2m view id too.

Also, I'm pretty sure this is only safe for a paused vCPU.  If the vCPU
isn't paused, then there's a TOCTOU race in the pagewalk code when
inspecting control registers.

> +        uint32_t pfec = PFEC_page_present;
> +        unsigned int page_order;
> +
> +        uint64_t gfn = paging_ga_to_gfn_cr3(v, cr3, ga, &pfec,
> &page_order);
> +        domctl->u.gva_to_gfn.addr = gfn;
> +        domctl->u.gva_to_gfn.page_order = page_order;

page_order is only not stack rubble if gfn is different to INVALID_GFN.

> +        if ( __copy_to_guest(u_domctl, domctl, 1) )
> +            ret = -EFAULT;

You want to restrict this to just the gva_to_gfn sub-portion.  No point
copying back more than necessary.

~Andrew



 


Rackspace

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