On 15.08.20 20:56, Julien Grall wrote:
Hi Julien.
Hi,
On 04/08/2020 15:01, Julien Grall wrote:
On 04/08/2020 08:49, Paul Durrant wrote:
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 931404c..b5fc066 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -26,11 +26,19 @@
#include "xg_private.h"
#include "xc_dom.h"
-#define NR_MAGIC_PAGES 4
+
#define CONSOLE_PFN_OFFSET 0
#define XENSTORE_PFN_OFFSET 1
#define MEMACCESS_PFN_OFFSET 2
#define VUART_PFN_OFFSET 3
+#define IOREQ_SERVER_PFN_OFFSET 4
+
+#define NR_IOREQ_SERVER_PAGES 8
+#define NR_MAGIC_PAGES (4 + NR_IOREQ_SERVER_PAGES)
+
+#define GUEST_MAGIC_BASE_PFN (GUEST_MAGIC_BASE >> XC_PAGE_SHIFT)
+
+#define special_pfn(x) (GUEST_MAGIC_BASE_PFN + (x))
Why introduce 'magic pages' for Arm? It's quite a horrible hack that
we have begun to do away with by adding resource mapping.
This would require us to mandate at least Linux 4.17 in a domain that
will run an IOREQ server. If we don't mandate this, the minimum
version would be 4.10 where DM OP was introduced.
Because of XSA-300, we could technically not safely run an IOREQ
server with existing Linux. So it is probably OK to enforce the use
of the acquire interface.
One more thing. We are using atomic operations on the IOREQ pages. As
our implementation is based on LL/SC instructions so far, we have
mitigation in place to prevent a domain DoS Xen. However, this relies
on the page to be mapped in a single domain at the time.
AFAICT, with the legacy interface, the pages will be mapped in both
the target and the emulator. So this would defeat the mitigation we
have in place.
Because the legacy interface is relying on foreign mapping, the page
has to be mapped in the target P2M. It might be possible to restrict
the access for the target by setting the p2m bits r, w to 0. This
would still allow the foreign mapping to work as we only check the p2m
type during mapping.
Anyway, I think we agreed that we want to avoid to introduce the
legacy interface. But I wanted to answer just for completeness and
keep a record of potential pitfalls with the legacy interface on Arm.
ok, the HVMOP plumbing on Arm will be dropped for non-RFC series. It
seems that xenforeignmemory_map_resource() does needed things. Of
course, the corresponding Linux patch to support
IOCTL_PRIVCMD_MMAP_RESOURCE was cherry-picked for that purpose (I am
currently using v4.14).
Thank you.
--
Regards,
Oleksandr Tyshchenko
