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

[PATCH v3] arm/ioreq: guard interaction data on read/write operations


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrii Chepurnyi <Andrii_Chepurnyi@xxxxxxxx>
  • Date: Thu, 5 Oct 2023 13:30:14 +0000
  • Accept-language: uk-UA, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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=6I+lOSuZlgvE8gmDgyPKVdwXA39J4ZWrm6F8aAwavz0=; b=kbEKrIBqD+dEQk8Twr3QSg0o8hrwvGIHJJOwDUK+nvs8CJQS4VelT59uwMNyg11BmcBQYHIriwY/6IB2heC9itp09+PIvIhQIWUmxteLZLjEX+Ufzjm0mbBSMFF90lYVXhV+dXBrOSRPESR/eDdXKHKmEtnhyMmSawzlj5CXXG+gqFDLYOTHod4GkX5Iy9SCW2JGigctR2tHFDIp6R0ycV9yTiDuMZfi1Rl/dzQ/1dwRWA2bF2YRi43mbK5BEI5NBsU/EGaYjtGU9lPcmQGLrUiPi9OOIvm3rkYlbNtt73mDYN+FbS3Hyb+B2bmsFvloamj6J5hPfKgzm44CAaGFjQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oLAZX3vn/XIFxWyymnQ8lKI0YuI1MeUN6qbUUowX7Uvf9i0GoKbgB+x0SMeElmolaLfENZahUq8vEnBLmNV/1pgnUENbQylJscb/xGeCeWZm0eec37lLxWHzb1MRu6djcaR4Bf9zav2eU6AWQlYC4drgzeFaKl+Ev6t4jCu3xLdIscSmwVJTcVcLL2TED006FwO72uFtPwoK75klYjlnXxeAuFtgps/q5Nl+vIKG5aKmgkf33jgVfy9VGUjG3YNb/HN/6acg6OEq2pF54rYbtOp3Z6Qz+rXtxgOxQ0Bh/VK6UevcMKMXiHu26IOUgruAIk9vgdGuztMF0n4W1xh9+g==
  • Cc: Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, "andrii.chepurnyi82@xxxxxxxxx" <andrii.chepurnyi82@xxxxxxxxx>, "Henry.Wang@xxxxxxx" <Henry.Wang@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Andrii Chepurnyi <Andrii_Chepurnyi@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Thu, 05 Oct 2023 13:30:43 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHZ95ASCSTawXXogECoWqu3XZfq/w==
  • Thread-topic: [PATCH v3] arm/ioreq: guard interaction data on read/write operations

For read operations, there's a potential issue when the data field
of the ioreq struct is partially updated in the response. To address
this, zero data field during read operations. This modification
serves as a safeguard against implementations that may inadvertently
partially update the data field in response to read requests.
For instance, consider an 8-bit read operation. In such cases, QEMU,
returns the same content of the data field with only 8 bits of
updated data. This behavior could potentially result in the
propagation of incorrect or unintended data to ioreq clients.
During a write access, the Device Model only need to know the content
of the bits associated with the access size (e.g. for 8-bit, the lower
8-bits). During a read access, the Device Model don't need to know any
value. So restrict the value it can access.

Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@xxxxxxxx>
Release-acked-by: Henry Wang <Henry.Wang@xxxxxxx>
---
 xen/arch/arm/ioreq.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/ioreq.c b/xen/arch/arm/ioreq.c
index 3bed0a14c0..5df755b48b 100644
--- a/xen/arch/arm/ioreq.c
+++ b/xen/arch/arm/ioreq.c
@@ -17,6 +17,8 @@ enum io_state handle_ioserv(struct cpu_user_regs *regs, 
struct vcpu *v)
 {
     const union hsr hsr = { .bits = regs->hsr };
     const struct hsr_dabt dabt = hsr.dabt;
+    const uint8_t access_size = (1U << dabt.size) * 8;
+    const uint64_t access_mask = GENMASK_ULL(access_size - 1, 0);
     /* Code is similar to handle_read */
     register_t r = v->io.req.data;
 
@@ -26,6 +28,12 @@ enum io_state handle_ioserv(struct cpu_user_regs *regs, 
struct vcpu *v)
     if ( dabt.write )
         return IO_HANDLED;
 
+    /*
+     * The Arm Arm requires the value to be zero-extended to the size
+     * of the register. The Device Model is not meant to touch the bits
+     * outside of the access size, but let's not trust that.
+     */
+    r &= access_mask;
     r = sign_extend(dabt, r);
 
     set_user_reg(regs, dabt.reg, r);
@@ -39,6 +47,8 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
     struct vcpu_io *vio = &v->io;
     const struct instr_details instr = info->dabt_instr;
     struct hsr_dabt dabt = info->dabt;
+    const uint8_t access_size = (1U << dabt.size) * 8;
+    const uint64_t access_mask = GENMASK_ULL(access_size - 1, 0);
     ioreq_t p = {
         .type = IOREQ_TYPE_COPY,
         .addr = info->gpa,
@@ -80,7 +90,13 @@ enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
 
     ASSERT(dabt.valid);
 
-    p.data = get_user_reg(regs, info->dabt.reg);
+    /*
+     * During a write access, the Device Model only need to know the content
+     * of the bits associated with the access size (e.g. for 8-bit, the lower 
8-bits).
+     * During a read access, the Device Model don't need to know any value.
+     * So restrict the value it can access.
+     */
+    p.data = p.dir ? 0 : get_user_reg(regs, info->dabt.reg) & access_mask;
     vio->req = p;
     vio->suspended = false;
     vio->info.dabt_instr = instr;
-- 
2.25.1



 


Rackspace

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