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

Re: [PATCH 2/3] x86/PV: replace assertions in '0' debug key stack dumping


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 18 Oct 2021 16:26:45 +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=8pAVrMRA+vG0xvh/Afkvx5KcAtWtLEotGVlwTALjwpk=; b=nUt4eTCff+5lcIAkuB1iVsQtFZYQKVRrsNaRI9nJO4vrrVMK6TtoGq7SBYcJ+A2+qYP596byiCmi9I+P4KyV0QgI6PPW3yXHLU4kV+Hw8qzVwGblGsAwxhoxd0M6zL2sfUpnY5LFZwOFOfIrW8/BGsfTiPk+CSug7b7zqDOOewfDwpeJrck0xLkerPAptM78lpqxYUDJYNASHO6zbAbZUsgz+pis+fJnVXdqxLyY7zomA4YEmOfDSd3sWVMop/7wxAXOsyiZAqDu1P8sfbtDS4CAWuGG26wXcmO4hAm+rCXww6/sYOMNfPYks3S7hRcRc6hqhKdMj86MFaWCqx5J/A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lgjXlRjHXzuSSnEbbuHbuxtsTrXQqE5bNeuIDeZbyM9Zbf8UxyV1CIDBMupmUeS0ZYwelvCYAsSxba6adZ4MfBTLcXlLBDo+n9nf9JxdZzitnhzdaCRgxVOi+LJ6lKKzIBkXoGSy1l+qDJsC5NdhPrcw7uhYaPs1CPNBqe7dn6pUIh9O7M5TC0VhrM08qE1BxIJ8dNjughv3VDkK2bUr3c1peI1vIE7raJ5rcKfrdsCyzVexBrh7eEZIKuW++dFHTdpOBE/UjtI+AYrHt2HnX5z/l1MHMDVZTc5lWLrdnhPGPj+7PQNKJROsUIoIHRegZsugeL28+dH2GsrPM3B+CA==
  • Authentication-results: esa1.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:27:02 +0000
  • Ironport-data: A9a23:gFRPMqzTahyThr4xscR6t+fswSrEfRIJ4+MujC+fZmUNrF6WrkUDz 2tLUTqEM/+KMzH8KN4jOtzi/UMD65GBnIIwG1M6/iAxQypGp/SeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnvopW1TYhSEUOZugH9IQM8aZfHAsLeNYYH1500s6w7dp2tQAbeWRWGthh /uj+6UzB3f9s9JEGjp8B3Wr8U4HUFza4Vv0j3RmDRx5lAa2e0o9VfrzEZqZPXrgKrS4K8bhL wr1IBNVyUuCl/slIovNfr8W6STmSJaKVeSFoiI+t6RPHnGuD8H9u0o2HKN0VKtZt9mGt90pk 45qmo6WcCECP5bnk+oMXD5SLy4raMWq+JefSZS+mcmazkmAeHrw2fR+SkoxOOX0+M4uXzsIr 6ZBbmlQMFbT3Ipaw5riIgVort4kI8TxepsWp1lrzC3DDOZgSpfGK0nPzYIFjGtp3pgSdRrYT 9soYiRISlfmWRERPn0tGLBvmsOBgnaqJlW0r3rK/PFqsgA/1jdZz7zFINfTPNuQSq19jkue4 27L4Wn9KhUbL8CEjyqI9Gq2ge3Clj+9X5gdfJW6/PN3hFyYxkQIFQYbE1C8pJGEZlWWAowFb RZOo2x38PZ0pBfDosTBswOQrSbf5TkzSfxpNcY70yqGxLvbxAylCT1RJtJeU+AOuMgzTD0s8 1aGmdL1GDBi2IGopWKhGqS89mzqZ3BERYMWTWpdF1Fduoi8yG0mpkuXFo4LLUKjsjHi9dgcK Rixpy8im65bs8cP06iqlbwsq2Px/saXJuLZCwO+Y45E0u+bTNP9D2BLwQKChRqlEGp/ZgPQ1 JTjs5PGhN3i9bnXyESwrBwlRdlFHcqtPjzGmkJIFJI87Tmr8HPLVdkOu20idRo4aJpYI26Bj KrvVeV5vs470JyCNvcfXm5MI55ykfiI+SrNB5g4keaikrAuLVTarUmClGab3nz3kVhErE3ME czzTCpYNl5DUf4P5GPvH481iOZ3rghjlTK7bc2qlHyPjOvBDEN5vJ9YaTNimMhit/jayOgUm v4CX/a3J+J3C7GnPXSLrNdOdDjn7xETXPjLliCeTcbaSiJOE2A9Ef7Bh7Qnfo1uhaNOkenUu Hq6XydlJJDX2hUr8C2GNSJubq3BR5F6oS5pNCAgJw/wiXMifZyu/OEUcJ5uJesr8+lqzPhVS fgZeprfXqQTG2qfozlNP4PgqIFCdQiwgV7cNSSSfzViLYVrQBbE+4G4c1K3pjUOFCe+qeA3v 6akilHAWZMGSgk7VJTWZfujwkmfp38YnO4uDULELsMKIBfn8ZRwKjy3hfgyepleJRLGzzqc9 gCXHRZH+rWd/95rqIHE3PnWoZ2oHu1yGlthM1PatbvmZzPH+meDwJNbVLradz7qS26pqr6pY v9Yzq+gPaRfzkpKqYd1D51i0bk6u4n0v7ZfwwlpQCfLYlCsBu8yK3WKx5AS5KhEx7sfsgqqQ EOfvNJdPOzRas/iFVcQIisjb/iCiq5IymWDs6xtLRWo/jJz8ZqGTV5WbkuFhyFqJbdoNJ8on LU6s8kM5g3j0hcnP75qVMyPG7hg+pDYb5gaiw==
  • Ironport-hdrordr: A9a23:lblueaxOirXawdyWkTCOKrPxseskLtp133Aq2lEZdPULSKKlfp GV88jziyWZtN9wYhEdcdDpAtjnfZr5z+8J3WBxB8bZYOCCggqVxe5ZnO7fKlHbaknDH6tmpN tdmstFeazN5DpB/L7HCWCDer5KqrT3k9HL9JfjJjVWPHpXgslbnnlE422gYzRLrWd9dP0E/M 323Ls5m9PsQwVbUu2LQl0+G8TTrdzCk5zrJTYAGh4c8QGLyRel8qTzHRS01goXF2on+8ZszU H11yjCoomzufCyzRHRk0fV8pRtgdPkjv9OHtaFhMQ5IijlziyoeINicbufuy1dmpDi1H8a1P 335zswNcV67H3cOkmzvBvWwgHllA0j7nfzoGXoyUfLkIjcfnYXGsBBjYVWfl/y8Ew7puxx16 pNwiawq4dXJQmoplW82/H4EzVR0makq3srluAey1ZFV5EFVbNXpYsDuGtIDZY7Gj7g4oxPKp guMCjl3ocVTbqmVQGdgoE2q+bcGkjbXy32DHTqg/blkAS/xxtCvgwlLM92pAZIyHtycegD2w xoWp4Y4I2mdfVmH56VMt1xN/dfOla9Mi4kD1jiVGgPNJt3cE4l+KSHqonc2omRCes1Jd0J6c 38bG8=
  • Ironport-sdr: PMr+irBcdrLguanZgSKl0gOt8nXPkQZZ582ymqkgvYAxpdBFEu2VoTGR5DJbwSyE43hU8h3uaI Ncnqi05Rx4d1Q9w4gDNKVsbIMEX/KtRZ1vOHN5Q8B8Xci1+A+fBa4l3WL8+QOaGhzJmGRolGzc 96e4w8SA+JXOKIDGZOx9CxeiysIr2Xiu4b4sBYpLiyTpmy+dSevp/kkdWPNCsSeO3P+B4i+Tnb EeqfqHChO80FiRr8zSQbyXTQTIFKne9l3Ylubc7nozGXcA6SYHv+lv+iLUFg6jTJhMZ67JlD8g 0eTlnJpVjLk8Z2kUhvJsim8K
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Sep 29, 2021 at 11:42:54AM +0200, Jan Beulich wrote:
> While it was me to add them, I'm afraid I don't see justification for
> the assertions: A vCPU may very well have got preempted while in user
> mode. Limit compat guest user mode stack dumps to the containing page
> (like is done when using do_page_walk()), and suppress their dumping
> altogether for 64-bit Dom0.

I'm slightly lost by this last sentence...

> Fixes: cc0de53a903c ("x86: improve output resulting from sending '0' over 
> serial")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> An alternative to suppressing the dump for 64-bit would be to make
> do_page_fault() guest-user-mode aware.
> 
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -254,7 +254,6 @@ static void compat_show_guest_stack(stru
>          struct vcpu *vcpu;
>          unsigned long mfn;
>  
> -        ASSERT(guest_kernel_mode(v, regs));
>          mfn = read_cr3() >> PAGE_SHIFT;
>          for_each_vcpu( v->domain, vcpu )
>              if ( pagetable_get_pfn(vcpu->arch.guest_table) == mfn )
> @@ -269,6 +268,8 @@ static void compat_show_guest_stack(stru
>              }
>              mask = PAGE_SIZE;
>          }
> +        else if ( !guest_kernel_mode(v, regs) )
> +            mask = PAGE_SIZE;
>      }
>  
>      for ( i = 0; i < debug_stack_lines * 8; i++ )
> @@ -328,7 +329,12 @@ static void show_guest_stack(struct vcpu
>      {
>          struct vcpu *vcpu;
>  
> -        ASSERT(guest_kernel_mode(v, regs));
> +        if ( !guest_kernel_mode(v, regs) )
> +        {
> +            printk("User mode stack\n");
> +            return;
> +        }

...as you seem to unconditionally prevent the dump regardless of
whether it's dom0 or domU as long as it's not a kernel stack?

I assume when running in PV 64bit mode user-space could be executing a
32bit program and hence Xen could then misprint the stack as a 64bit
one?

Thanks, Roger.



 


Rackspace

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