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

Re: [PATCH 1/3] x86/PV: make '0' debug key dump Dom0's stacks again


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 18 Oct 2021 16:13:33 +0200
  • 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=Dc+qMydesX1h0EmgRj4Svje9E02+vYvUHM+dhZKnqMs=; b=SOFK5m92noehyCXnq4OG9tdhKvGu2hfsnPBoYaaqdxPIwBUmaNEzanWpQBjp7N0ufJ9MvuMTA5ua2Us+M/AacDLRJC0PCtv81xdUac7xJ6VFBjsOj/kEVTH1WCfa5g+bjiLLi6HvIIAUaf83lyxUVfqU9sl8IPL/w47Edd+O1/CAdYDO79rYs2kTBCLzT2y9dngYoNtl8ETOVshZD0bnsdzESQW/NPCSKrOrRCBMaG8D5ZwKDTp3Mww6j3QQ1YshIDgVKRt5/3wIcWUhs09lIJzB6DxsEhqctRRX4CZro/KXOHGzKT1RAxU6sx45hs7fW/PXPGdZfAaNeRBcYhuXLg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P4YWzFN+kTupUBoAbvXhSOlYlAiGNQ2xod2Q8x6uk77MpIoudk5cpsbwQib14eGZNpYXG9Ep/NJexvVsC2g0J2e7pmOBQvJDEb7h72HPjUWgWe1FBYyu3Uuoes0X05HPrLhpnPOnMKToyEJZxkda4yAmWWzv61uJsSK7417dOj0uL3Z2PvWRG7B7AT6litTrZp6uPzsm1wf3+h7mCMq/o9fj6ZrA3RlZg66XmGzTLh4KOEnRdzNrZo4svz+yb8e/JProwUIbQ2ZLZlvfIsXxkoyL/Cy1gLzONk1kquh0eciRvniM8UFUPTJ161qwsZVQnIUSNc46aMYnkk4+HZAkew==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 18 Oct 2021 14:13:57 +0000
  • Ironport-data: A9a23:1/B3fa2YqSE9j1fn1vbD5Qh2kn2cJEfYwER7XKvMYLTBsI5bp2cOm 2JJDGmGbv6NNzGheop2OYq/9U0BvMDdzd81QAdspC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkS5PE3oHJ9RGQ74nRLlbHILOCan0ZqTNMEn970Es7wr5h2OaEvPDia++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFMZH4rHomjLmOQf2VhNrXSq 9Avbl2O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/TrS+NbPqsTbZIhhUlrZzqhg81R8 O1V74OMZjwnPIaRpeNAXEFCDHQrVUFG0OevzXmXtMWSywvNcmf2wuUoB0YzVWEa0r8pWycUr 6VecW1TKEDY7w616OvTpu1EnMMsIdOtJIoCknph0SvYHbAtRpWrr6DiuIIEg25h35Am8fD2P sYeYBFAQzP5OxxVN1I1M9FlsNv1iSyqG9FfgA3M/vdmi4TJ9yRu1JD9PdyTfcaFLe1Fk0Ddq m/Y8mDRBhABKMfZ2TeD6mirhOLEgWX8Qo16PL+y++NugVaT7ncOExBQXly+ycRVkWbnBYgZc RZNvHNz8+5iryRHU+URQTWkvV68hgZGROZ/KOM4w1ywzffbuxyGUz1soiF6VPQqs8o/RDoP3 1CPns/0CTEHjIB5WU5x5Z/P8mvsYXl9wXsqIHZeF1NcsoaLTJQb10qXFr5e/LiJYsoZ8N0a6 wuBqzQinP0thMoP2rTTEbvv0m/0+MahouLY4GzqsoOZAuFROdbNi2+AswGzARN8wGCxFAjpU J8swJD20Qz2JcvR/BFhuc1UdF1T296LMSfHnXlkFIQ7+jKm9haLJN4LvG0veRYzbppeKFcFh XM/XysLtfe/21PxNcdKj3+ZUZx2ncAM6/y0PhwrUja+SscoL1LWlM2fTUWRw3rsgCARfVIXY v+mnTKXJS9CU8xPlWPuL89EiOND7n1ulAv7GMGgpzz6gOX2WZJgYepcWLd4Rrtit/3sTcS82 4s3CvZmPD0EDLShP3WKqNNKRb3IRFBiba3LRwVsXrfrCiJtGX07Cu+XxrUkeod/mL9SmPuO9 Xa4MnK0AnKk7ZEeAQnVOH1ldp31WpNz8SAyMSA2ZA760Hk/e4e/qqwYcsJvL7Ug8eViy99yT uUEJJrcUqgeFGyf9mRPd4T5oaxjaA+v2VCEMR26bWVtZJVnXQHIpIPpJ1O96CkUAyOrnsIiu Ln8hBjDSJ8OSl06XsbbYf6i1X2run0ZlL4gVkfEOIALKk7t7JJrO2r6ifpue5MALhDKxz270 QeKAEhH+bmR8tFtqNSQ3PKKtYakFed6D3F2JWiD4ObkLzTe80qi3ZREDLSCcwfCWT6m466lf +hUka3xaaVVgFZQvoNgOL931qZitcD3rrpXwwk4TnXGa1OnVuFpLnWchJQds6RMwvlSuBesW 1LJ8d5fYO3bNMTgGV8XBQwkcuXciq1ExmiMtaw4cBfg+St63LubSkEDbRCDhRtUIKZxLI54k /wqv9Qb6lDnhxcnWjpcYvu4K4hYwqQ8bpga
  • Ironport-hdrordr: A9a23:mPhO1K4uf+8oJq8OHAPXwMzXdLJyesId70hD6qkXc20zTiX4rb HLoB1/73TJYVkqNE3I9eruBEDiexPhHPxOj7X5VI3KNGOKhILCFuBfxLqn7zr8GzDvss5xvJ 0QFpSW0eeAbmSSW/yKgjWFLw==
  • Ironport-sdr: ML9E70PRLNv3PU8uRxbA7/TFLZ0wiKMdcD03IEpxLHLRbZJ7+LXgYqQ8XnQmzrJDQgBFReocJj ekWAkeEygZ91sFXFUt6HXb1JFOHT2SYg0lqLoae7TflIWyp+rmKY50BjMeKqxEY8PGy3AUUuMY BFR0Ul/SPl0KLc3MaB0kPWzKDIK0GOxVQWxCQqpGlx+F5wjg/SRzjP0tv9AzF3IQml4i8SGD2L I51TJzWUHlfif0agtK6C2tFehCC9F/GMRVHkbSSMIRH8L55y2aDK9jtpvqVTD2qFOTWHwNVZAK CRFvBfFcrO38cTt732Dm+HOq
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Sep 29, 2021 at 11:42:34AM +0200, Jan Beulich wrote:
> The conversion to __get_guest() failed to account for the fact that for
> remote vCPU-s dumping gets done through a pointer obtained from
> map_domain_page(): __get_guest() arranges for (apparent) accesses to
> hypervisor space to cause #GP(0).
> 
> Fixes: 6a1d72d3739e ('x86: split __{get,put}_user() into "guest" and "unsafe" 
> variants')
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Using get_unsafe() might be an option as well, instead of the added
> extra conditional.

A third option might be to place them in a non Xen private VA range,
like we do for the compat argument translation. That's however too
much IMO.

> 
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -275,7 +275,9 @@ static void compat_show_guest_stack(stru
>      {
>          if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask )
>              break;
> -        if ( __get_guest(addr, stack) )
> +        if ( stack_page )
> +            addr = *stack;
> +        else if ( __get_guest(addr, stack) )
>          {
>              if ( i != 0 )
>                  printk("\n    ");
> @@ -344,7 +346,9 @@ static void show_guest_stack(struct vcpu
>      {
>          if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask )
>              break;
> -        if ( __get_guest(addr, stack) )
> +        if ( stack_page )
> +            addr = *stack;

I don't really have a strong opinion regarding this or the usage of
get_unsafe. When v == current we have the extra protection of being
sure no private Xen mappings are accessed, but that's only for a
single vCPU at most, at which point we might just use get_unsafe
uniformly. I guess I have a slight preference for get_unsafe because
using get_guest doesn't really get us anything.

If you keep it in the current form, or decide to switch to
get_unsafe:

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks, Roger.



 


Rackspace

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