From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
Cc: "David Hildenbrand" <david@redhat.com>,
"Alexey Kardashevskiy" <aik@ozlabs.ru>,
"Peter Xu" <peterx@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: [RFC PATCH] physmem: Do not allow unprivileged device map privileged memory
Date: Fri, 3 Sep 2021 17:38:20 +0200 [thread overview]
Message-ID: <20210903153820.686913-1-philmd@redhat.com> (raw)
Since commits cc05c43ad94..42874d3a8c6 ("memory: Define API for
MemoryRegionOps to take attrs and return status") the Memory API
returns a zero (MEMTX_OK) response meaning success, anything else
indicating a failure.
In commits c874dc4f5e8..2f7b009c2e7 ("Make address_space_map() take
a MemTxAttrs argument") we updated the AddressSpace and FlatView
APIs but forgot to check the returned value by the FlatView from
the MemoryRegion.
Adjust that now, only returning a non-NULL address if the transaction
succeeded with the requested memory attributes.
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
RFC because this could become a security issue in a core component,
however currently all callers pass MEMTXATTRS_UNSPECIFIED.
---
include/exec/memory.h | 3 ++-
softmmu/physmem.c | 16 ++++++++++------
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index c3d417d317f..488d2ecdd09 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -2706,7 +2706,8 @@ bool address_space_access_valid(AddressSpace *as, hwaddr addr, hwaddr len,
*
* May map a subset of the requested range, given by and returned in @plen.
* May return %NULL and set *@plen to zero(0), if resources needed to perform
- * the mapping are exhausted.
+ * the mapping are exhausted or if the physical memory region is not accessible
+ * for the requested memory attributes.
* Use only for reads OR writes - not for read-modify-write operations.
* Use cpu_register_map_client() to know when retrying the map operation is
* likely to succeed.
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index 23e77cb7715..802c339f6d2 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -3188,15 +3188,19 @@ void *address_space_map(AddressSpace *as,
/* Avoid unbounded allocations */
l = MIN(l, TARGET_PAGE_SIZE);
bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, l);
+
+ if (!is_write) {
+ if (flatview_read(fv, addr, attrs, bounce.buffer, l) != MEMTX_OK) {
+ qemu_vfree(bounce.buffer);
+ *plen = 0;
+ return NULL;
+ }
+ }
+
bounce.addr = addr;
bounce.len = l;
-
- memory_region_ref(mr);
bounce.mr = mr;
- if (!is_write) {
- flatview_read(fv, addr, MEMTXATTRS_UNSPECIFIED,
- bounce.buffer, l);
- }
+ memory_region_ref(mr);
*plen = l;
return bounce.buffer;
--
2.31.1
next reply other threads:[~2021-09-03 15:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 15:38 Philippe Mathieu-Daudé [this message]
2021-09-03 21:02 ` [RFC PATCH] physmem: Do not allow unprivileged device map privileged memory Peter Xu
2021-09-07 13:24 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210903153820.686913-1-philmd@redhat.com \
--to=philmd@redhat.com \
--cc=aik@ozlabs.ru \
--cc=david@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).