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

Re: [PATCH 2/2][4.17] x86emul: pull permission check ahead for REP INS/OUTS


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Mon, 10 Oct 2022 18:08:09 +0000
  • Accept-language: en-GB, en-US
  • 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=PnZoCexthh/EXunivWF7KSnsSKgHi7Gq9hM7Q3WRMC8=; b=PHA3JzhDzf7HwGaACHEhm3g54FKAoeEVKQZ3YF1hNvkP3rvU3+c19DSmT/XQI93qOo3+/42Ct5jSAGkZwFsZm3RYCy4PYGk/+wteQMHcBziywFO8cFDofz5yvYi79iM0XB+W9zRmV6RR2WrI+gm9tJOdtFw1WUd/7FZ1lRqgR1ynkCPb+El6XxxZlCNhdKBnbMtiXqpF8aX43Uc4upoI6PmYZsOTOT1iB3G2Qu/Q9udgMk0bHyn0zsUSwa9LHXCA2wYhn2G2e+TAplUz5neqlxM0yVgn0MZ3HEKULqsZeB5JCkhg01f7T+ONw/+hXWQ1WK6rkXr1EWTZyao3+ijM4g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EZ/8ONue2NH2c7wmoRYCoPyGStpJbmoCrNgTc3mHHpM6KHFUiog0lPtp0sDk/k1VrNLUXCsvMDkfpRQkBy4XXxsLBBhtcosjyePefPG+RRrZsXXpgDmwX1zq3g6RIqVVjUJJ7LbVUQVAv3FaN8JTl7vge4qp/OmgsQdZHaRLHGxCT9ETd5O5AhxMAWnpKVgtcxql42J1JLAWV3y5VZB5g6WmCenAi3Gm80scx8mDBQmSYEvNOnxLQHSQ9UXpgRnahcj2DA8k/TEFiicjOS+LQJrb3vWIGP6voHvZ54cyEs9cDmLuAGZriUTjgiKM7Gf5ZyNWvy6x74ywY9MS+HO36Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>
  • Delivery-date: Mon, 10 Oct 2022 18:08:46 +0000
  • Ironport-data: A9a23:j6SxlKC33X/cNhVW/xriw5YqxClBgxIJ4kV8jS/XYbTApGt01TBWm jYYWz+FPvrfYWr8ft51Odnn9kMD65WGyNIxQQY4rX1jcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BCpC48T8mk/ngqoPUUIbsIjp2SRJvVBAvgBdin/9RqoNziJ2yDhjlV ena+qUzA3f4nW8pWo4ow/jb8kk25K2q4GlwUmEWPpingnePzxH5M7pHTU2BByOQapVZGOe8W 9HCwNmRlo8O105wYj8Nuu+TnnwiGtY+DyDX4pZlc/HKbix5jj4zys4G2M80Mi+7vdkrc+dZk 72hvbToIesg0zaldO41C3G0GAkmVUFKFSOuzdFSfqV/wmWfG0YAzcmCA2k7DZM32OFzLF1cq /ApLis3bAGxtem5lefTpulE3qzPLeHNFaZG4DRF8mucCvwrB5feX6/N+NlUmi8qgdxDFurfY MxfbidzaBPHYFtEPVJ/5JAWxb/0wCWgNWMG7g7FzUY0yzG7IAhZ+b7hKtfKPPeNQt1YhB2wr WPa5WXpRBodMbRzzBLVriP227KQxksXXqoJT5+Fz8dhg2aT/Ug/JBM6c1mQr+uA3xvWt9V3b hZ8FjAVhao4+VGvT9L9dwalu3PCtRkZM/JAHut/5AyTx6785weCGnNCXjNHcMYhtsI9WXotz FDht8ztLSxitvuSU3313peZqymjfxccK2AqbDUBCwAC5rHeTJobixvOSpNmD/Szh9isQzXom WjW/G45mqkZitMN2+Oj51fbjjmwp5/PCAko+gHQWWHj5QR8DGK4W7GVBZHgxa4oBO6kopOp5 RDoR+D2ADgyMKyw
  • Ironport-hdrordr: A9a23:JDptpqMlAIYJRcBcT2L155DYdb4zR+YMi2TDiHoddfUFSKalfp 6V98jzjSWE8wr4WBkb6LO90DHpewKQyXcH2/hqAV7EZnirhILIFvAp0WKG+VHd8kLFh4lgPM tbEpSWTeeAdWSS7vyKrzVQcexQpuVvmZrA7Yix854ud3ASV0gK1XYaNu/vKDwTeOAwP+tdKH Pz3Kp6jgvlXU5SQtWwB3EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUiSw71M7aXdi0L0i+W /Kn0jS/aO4qcy2zRfayiv684lWot380dFObfb8yvT9aw+cyTpAVr4RHoFqjwpF5N1HL2xa1+ Ukli1QffibLUmhOF1d7yGdgjUImwxelkMKgWXo/UcL5/aJCg7SQvAx+76wOHHimjUdlcA536 RR022DsZ1LSRvGgSTm/tDNEwpnj0yuvBMZ4KcuZlFkIPwjgYVq3Poi1VIQFI1FEDPx6YghHu UrBMbA5OxOeVffa3zCpGFgzNGlQ3x2R369MwM/k93Q1yITkGFyzkMeysBalnAc9IglQ50B4+ jfKKxnmLxHU8dTZ6NgA+UKR9exFwX2MFrxGXPXJU6iGLAMOnrLpZKy6LIp5PuycJhN15c2kI SpaiItiYfzQTOaNSSj5uw5zvmWehTNYd3E8LAv27Fp/rvhWbHsLSqPDFgzjsrImYRsPvHm
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHY2YU75mqlIJYsj0WxLAJHeHNvXK4H83eA
  • Thread-topic: [PATCH 2/2][4.17] x86emul: pull permission check ahead for REP INS/OUTS

On 06/10/2022 14:11, Jan Beulich wrote:
> Based on observations on a fair range of hardware from both primary
> vendors even zero-iteration-count instances of these insns perform the
> port related permission checking first.
>
> Fixes: fe300600464c ("x86: Fix emulation of REP prefix")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> Partly RFC for this not being documented anywhere; inquiry pending.

Intel do actually document this in two roundabout ways.

1) The order of checks in the pseudocode.  Multiple times in the past,
Intel have said that the order of checks in pseudocode is authoritative.

2) This paragraph I've just found at the end of the INS description.

"These instructions may read from the I/O port without writing to the
memory location if an exception or VM exit occurs due to the write (e.g.
#PF). If this would be problematic, for example because the I/O port
read has side-effects, software should ensure the write to the memory
location does not cause an exception or VM exit."

This makes it clear that the IO port is read before the memory operand
is interpreted.  (As a tangent, while the SDM statement is all true,
it's entirely useless advice for e.g. a migrating VM.)


Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, preferably with
some of ^ discussed in the commit message.

>
> The referenced commit is still not really the one, but before it REP
> handling was so broken that I didn't want to go hunt further.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4248,14 +4248,15 @@ x86_emulate(
>          goto imul;
>  
>      case 0x6c ... 0x6d: /* ins %dx,%es:%edi */ {
> -        unsigned long nr_reps = get_rep_prefix(false, false);
> +        unsigned long nr_reps;
>          unsigned int port = _regs.dx;
>  
>          dst.bytes = !(b & 1) ? 1 : (op_bytes == 8) ? 4 : op_bytes;
> -        dst.mem.seg = x86_seg_es;
> -        dst.mem.off = truncate_ea_and_reps(_regs.r(di), nr_reps, dst.bytes);
>          if ( (rc = ioport_access_check(port, dst.bytes, ctxt, ops)) != 0 )
>              goto done;
> +        nr_reps = get_rep_prefix(false, false);
> +        dst.mem.off = truncate_ea_and_reps(_regs.r(di), nr_reps, dst.bytes);
> +        dst.mem.seg = x86_seg_es;

As a further observation, both the Intel and AMD manuals elude to the
use of unsegmented memory space for the 64bit forms of these.

However, as both %ds (outs) and %es (ins) ignore their bases in 64bit
mode, I can't think of any practical consequences of conditionally not
using x86_seg_none here.

~Andrew

 


Rackspace

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