All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
@ 2017-10-24 10:19 Petre Pircalabu
  2017-11-20  9:35 ` Petre Ovidiu PIRCALABU
                   ` (3 more replies)
  0 siblings, 4 replies; 26+ messages in thread
From: Petre Pircalabu @ 2017-10-24 10:19 UTC (permalink / raw)
  To: xen-devel
  Cc: Petre Pircalabu, sstabellini, wei.liu2, Razvan Cojocaru,
	konrad.wilk, George.Dunlap, andrew.cooper3, ian.jackson, tim,
	jbeulich

From: Razvan Cojocaru <rcojocaru@bitdefender.com>

For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addresses the gap.

HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
hence with the original altp2m design, where domains are allowed - with the
proper altp2m access rights - to alter these settings), in the absence of an
official position on the issue from the original altp2m designers.

Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>

---

Changed since v2:
    * Added support for compat arguments translation

Changed since v3:
    * Replaced  __copy_to_guest with __copy_field_to_guest
    * Removed the un-needed parentheses.
    * Fixed xlat.lst ordering
    * Added comment to patch description explaining why the
    functionality was added as an HVMOP.
    * Guard using XEN_GENERATING_COMPAT_HEADERS the hvmmem_type_t definition.
    This will prevent suplicate definitions to be generated for the
    compat equivalent.
    * Added comment describing the manual translation of
    xen_hvm_altp2m_op_t generic fields from compat_hvm_altp2m_op_t.

Changed since v4:
    * Changed the mask parameter to 0x3F.
    * Split long lines.
    * Added "improperly named HVMMEM_(*)" to the comment explaining the
    XEN_GENERATING_COMPAT_HEADERS guard.
    * Removed typedef and XEN_GUEST_HANDLE for xen_hvm_altp2m_set_mem_access_multi.
    * Copied the "opaque" field to guest in compat_altp2m_op.
    * Added build time test to check if the size of
    xen_hvm_altp2m_set_mem_access_multi at least equal to the size of
    compat_hvm_altp2m_set_mem_access_multi.

Changed since v5:
    * Changed the domid parameter type to uint32_t to match 5b42c82f.
    * Added comment to explain why the 0x3F value was chosen.
    * Fixed switch indentation in compat_altp2m_op.
    * Changed the condition used to check if the opaque field has to
    be copied to the guest.
    * Added CHECK_hvm_altp2m_op and CHECK_hvm_altp2m_set_mem_access_multi.

Changed since v6:
    * Removed trailing semicolon from the definitions of CHECK_hvm_altp2m_op
    and CHECK_hvm_altp2m_set_mem_access_multi.
    * Removed BUILD_BUG_ON check.
    * Added comment describing the reason for manually defining the CHECK_
    macros.
    * Added ASSERT_UNREACHABLE as the default switch label action in
    compat_altp2m_op.
    * Added ASSERT(rc == __HYPERVISOR_hvm_op) to make sure the return
    code was actually sey by hypercall_create_continuation.

Changed since v7:
    * Changed the patch title.
---
 tools/libxc/include/xenctrl.h   |   3 +
 tools/libxc/xc_altp2m.c         |  40 ++++++++++++
 xen/arch/x86/hvm/hvm.c          | 138 +++++++++++++++++++++++++++++++++++++++-
 xen/include/Makefile            |   1 +
 xen/include/public/hvm/hvm_op.h |  36 +++++++++--
 xen/include/xlat.lst            |   1 +
 6 files changed, 213 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 666db0b..f171668 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1974,6 +1974,9 @@ int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
 int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
                          uint16_t view_id, xen_pfn_t old_gfn,
                          xen_pfn_t new_gfn);
+int xc_altp2m_set_mem_access_multi(xc_interface *handle, uint32_t domid,
+                                   uint16_t view_id, uint8_t *access,
+                                   uint64_t *pages, uint32_t nr);
 
 /** 
  * Mem paging operations.
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 07fcd18..e170fe3 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -213,3 +213,43 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
     return rc;
 }
 
+int xc_altp2m_set_mem_access_multi(xc_interface *xch, uint32_t domid,
+                                   uint16_t view_id, uint8_t *access,
+                                   uint64_t *pages, uint32_t nr)
+{
+    int rc;
+
+    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+    DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+    DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
+                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+    arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+    if ( arg == NULL )
+        return -1;
+
+    arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+    arg->cmd = HVMOP_altp2m_set_mem_access_multi;
+    arg->domain = domid;
+    arg->u.set_mem_access_multi.view = view_id;
+    arg->u.set_mem_access_multi.nr = nr;
+
+    if ( xc_hypercall_bounce_pre(xch, pages) ||
+         xc_hypercall_bounce_pre(xch, access) )
+    {
+        PERROR("Could not bounce memory for HVMOP_altp2m_set_mem_access_multi");
+        return -1;
+    }
+
+    set_xen_guest_handle(arg->u.set_mem_access_multi.pfn_list, pages);
+    set_xen_guest_handle(arg->u.set_mem_access_multi.access_list, access);
+
+    rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+		  HYPERCALL_BUFFER_AS_ARG(arg));
+
+    xc_hypercall_buffer_free(xch, arg);
+    xc_hypercall_bounce_post(xch, access);
+    xc_hypercall_bounce_post(xch, pages);
+
+    return rc;
+}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 205b4cb..02e280d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -73,6 +73,8 @@
 #include <public/arch-x86/cpuid.h>
 #include <asm/cpuid.h>
 
+#include <compat/hvm/hvm_op.h>
+
 bool_t __read_mostly hvm_enabled;
 
 #ifdef DBG_LEVEL_0
@@ -4451,6 +4453,7 @@ static int do_altp2m_op(
     case HVMOP_altp2m_destroy_p2m:
     case HVMOP_altp2m_switch_p2m:
     case HVMOP_altp2m_set_mem_access:
+    case HVMOP_altp2m_set_mem_access_multi:
     case HVMOP_altp2m_change_gfn:
         break;
     default:
@@ -4568,6 +4571,37 @@ static int do_altp2m_op(
                                     a.u.set_mem_access.view);
         break;
 
+    case HVMOP_altp2m_set_mem_access_multi:
+        if ( a.u.set_mem_access_multi.pad ||
+             a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr )
+        {
+            rc = -EINVAL;
+            break;
+        }
+
+        /*
+         * The mask was set (arbitrary) to 0x3F to match the value used for
+         * MEMOP, despite the fact there are no encoding limitations for the
+         * start parameter.
+         */
+        rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
+                                      a.u.set_mem_access_multi.access_list,
+                                      a.u.set_mem_access_multi.nr,
+                                      a.u.set_mem_access_multi.opaque,
+                                      0x3F,
+                                      a.u.set_mem_access_multi.view);
+        if ( rc > 0 )
+        {
+            a.u.set_mem_access_multi.opaque = rc;
+            if ( __copy_field_to_guest(guest_handle_cast(arg, xen_hvm_altp2m_op_t),
+                                       &a, u.set_mem_access_multi.opaque) )
+                rc = -EFAULT;
+            else
+                rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
+                                                   HVMOP_altp2m, arg);
+        }
+        break;
+
     case HVMOP_altp2m_change_gfn:
         if ( a.u.change_gfn.pad1 || a.u.change_gfn.pad2 )
             rc = -EINVAL;
@@ -4586,6 +4620,108 @@ static int do_altp2m_op(
     return rc;
 }
 
+DEFINE_XEN_GUEST_HANDLE(compat_hvm_altp2m_op_t);
+
+/*
+ * Manually define the CHECK_ macros for hvm_altp2m_op and
+ * hvm_altp2m_set_mem_access_multi as the generated versions can't handle
+ * correctly the translation of all fields from compat_(*) to xen_(*).
+ */
+#ifndef CHECK_hvm_altp2m_op
+#define CHECK_hvm_altp2m_op \
+    CHECK_SIZE_(struct, hvm_altp2m_op); \
+    CHECK_FIELD_(struct, hvm_altp2m_op, version); \
+    CHECK_FIELD_(struct, hvm_altp2m_op, cmd); \
+    CHECK_FIELD_(struct, hvm_altp2m_op, domain); \
+    CHECK_FIELD_(struct, hvm_altp2m_op, pad1); \
+    CHECK_FIELD_(struct, hvm_altp2m_op, pad2)
+#endif /* CHECK_hvm_altp2m_op */
+
+#ifndef CHECK_hvm_altp2m_set_mem_access_multi
+#define CHECK_hvm_altp2m_set_mem_access_multi \
+    CHECK_FIELD_(struct, hvm_altp2m_set_mem_access_multi, view); \
+    CHECK_FIELD_(struct, hvm_altp2m_set_mem_access_multi, pad); \
+    CHECK_FIELD_(struct, hvm_altp2m_set_mem_access_multi, nr); \
+    CHECK_FIELD_(struct, hvm_altp2m_set_mem_access_multi, opaque)
+#endif /* CHECK_hvm_altp2m_set_mem_access_multi */
+
+CHECK_hvm_altp2m_op;
+CHECK_hvm_altp2m_set_mem_access_multi;
+
+static int compat_altp2m_op(
+    XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+    int rc = 0;
+    struct compat_hvm_altp2m_op a;
+    union
+    {
+        XEN_GUEST_HANDLE_PARAM(void) hnd;
+        struct xen_hvm_altp2m_op *altp2m_op;
+    } nat;
+
+    if ( !hvm_altp2m_supported() )
+        return -EOPNOTSUPP;
+
+    if ( copy_from_guest(&a, arg, 1) )
+        return -EFAULT;
+
+    if ( a.pad1 || a.pad2 ||
+         (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
+        return -EINVAL;
+
+    set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLAT_VIRT_BASE);
+
+    switch ( a.cmd )
+    {
+    case HVMOP_altp2m_set_mem_access_multi:
+#define XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list(_d_, _s_); \
+        guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
+#define XLAT_hvm_altp2m_set_mem_access_multi_HNDL_access_list(_d_, _s_); \
+        guest_from_compat_handle((_d_)->access_list, (_s_)->access_list)
+        XLAT_hvm_altp2m_set_mem_access_multi(&nat.altp2m_op->u.set_mem_access_multi,
+                                             &a.u.set_mem_access_multi);
+#undef XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list
+#undef XLAT_hvm_altp2m_set_mem_access_multi_HNDL_access_list
+        break;
+    default:
+        return do_altp2m_op(arg);
+    }
+
+    /* Manually fill the common part of the xen_hvm_altp2m_op structure. */
+    nat.altp2m_op->version  = a.version;
+    nat.altp2m_op->cmd      = a.cmd;
+    nat.altp2m_op->domain   = a.domain;
+    nat.altp2m_op->pad1     = a.pad1;
+    nat.altp2m_op->pad2     = a.pad2;
+
+    rc = do_altp2m_op(nat.hnd);
+
+    switch ( a.cmd )
+    {
+    case HVMOP_altp2m_set_mem_access_multi:
+        /*
+         * The return code can be positive only if it is the return value
+         * of hypercall_create_continuation. In this case, the opaque value
+         * must be copied back to the guest.
+         */
+        if ( rc > 0 )
+        {
+            ASSERT(rc == __HYPERVISOR_hvm_op);
+            a.u.set_mem_access_multi.opaque =
+                nat.altp2m_op->u.set_mem_access_multi.opaque;
+            if ( __copy_field_to_guest(guest_handle_cast(arg,
+                                                         compat_hvm_altp2m_op_t),
+                                       &a, u.set_mem_access_multi.opaque) )
+                rc = -EFAULT;
+        }
+        break;
+    default:
+        ASSERT_UNREACHABLE();
+    }
+
+    return rc;
+}
+
 static int hvmop_get_mem_type(
     XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg)
 {
@@ -4733,7 +4869,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
         break;
 
     case HVMOP_altp2m:
-        rc = do_altp2m_op(arg);
+        rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg);
         break;
 
     default:
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 1299b19..8fc6e2b 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -28,6 +28,7 @@ headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
 headers-$(CONFIG_X86)     += compat/arch-x86/xen-$(compat-arch-y).h
 headers-$(CONFIG_X86)     += compat/hvm/hvm_vcpu.h
 headers-$(CONFIG_X86)     += compat/hvm/dm_op.h
+headers-$(CONFIG_X86)     += compat/hvm/hvm_op.h
 headers-y                 += compat/arch-$(compat-arch-y).h compat/pmu.h compat/xlat.h
 headers-$(CONFIG_FLASK)   += compat/xsm/flask_op.h
 
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index 0bdafdf..12de88ac 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -83,6 +83,13 @@ DEFINE_XEN_GUEST_HANDLE(xen_hvm_set_pci_link_route_t);
 /* Flushes all VCPU TLBs: @arg must be NULL. */
 #define HVMOP_flush_tlbs          5
 
+/*
+ * hvmmem_type_t should not be defined when generating the corresponding
+ * compat header. This will ensure that the improperly named HVMMEM_(*)
+ * values are defined only once.
+ */
+#ifndef XEN_GENERATING_COMPAT_HEADERS
+
 typedef enum {
     HVMMEM_ram_rw,             /* Normal read/write guest RAM */
     HVMMEM_ram_ro,             /* Read-only; writes are discarded */
@@ -102,6 +109,8 @@ typedef enum {
                                   to HVMMEM_ram_rw. */
 } hvmmem_type_t;
 
+#endif /* XEN_GENERATING_COMPAT_HEADERS */
+
 /* Hint from PV drivers for pagetable destruction. */
 #define HVMOP_pagetable_dying        9
 struct xen_hvm_pagetable_dying {
@@ -237,6 +246,20 @@ struct xen_hvm_altp2m_set_mem_access {
 typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
 DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
 
+struct xen_hvm_altp2m_set_mem_access_multi {
+    /* view */
+    uint16_t view;
+    uint16_t pad;
+    /* Number of pages */
+    uint32_t nr;
+    /* Used for continuation purposes */
+    uint64_t opaque;
+    /* List of pfns to set access for */
+    XEN_GUEST_HANDLE(const_uint64) pfn_list;
+    /* Corresponding list of access settings for pfn_list */
+    XEN_GUEST_HANDLE(const_uint8) access_list;
+};
+
 struct xen_hvm_altp2m_change_gfn {
     /* view */
     uint16_t view;
@@ -268,15 +291,18 @@ struct xen_hvm_altp2m_op {
 #define HVMOP_altp2m_set_mem_access       7
 /* Change a p2m entry to have a different gfn->mfn mapping */
 #define HVMOP_altp2m_change_gfn           8
+/* Set access for an array of pages */
+#define HVMOP_altp2m_set_mem_access_multi 9
     domid_t domain;
     uint16_t pad1;
     uint32_t pad2;
     union {
-        struct xen_hvm_altp2m_domain_state       domain_state;
-        struct xen_hvm_altp2m_vcpu_enable_notify enable_notify;
-        struct xen_hvm_altp2m_view               view;
-        struct xen_hvm_altp2m_set_mem_access     set_mem_access;
-        struct xen_hvm_altp2m_change_gfn         change_gfn;
+        struct xen_hvm_altp2m_domain_state         domain_state;
+        struct xen_hvm_altp2m_vcpu_enable_notify   enable_notify;
+        struct xen_hvm_altp2m_view                 view;
+        struct xen_hvm_altp2m_set_mem_access       set_mem_access;
+        struct xen_hvm_altp2m_change_gfn           change_gfn;
+        struct xen_hvm_altp2m_set_mem_access_multi set_mem_access_multi;
         uint8_t pad[64];
     } u;
 };
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 4346cbe..e3fb0c1 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -71,6 +71,7 @@
 ?	dm_op_set_pci_intx_level	hvm/dm_op.h
 ?	dm_op_set_pci_link_route	hvm/dm_op.h
 ?	dm_op_track_dirty_vram		hvm/dm_op.h
+!	hvm_altp2m_set_mem_access_multi	hvm/hvm_op.h
 ?	vcpu_hvm_context		hvm/hvm_vcpu.h
 ?	vcpu_hvm_x86_32			hvm/hvm_vcpu.h
 ?	vcpu_hvm_x86_64			hvm/hvm_vcpu.h
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply related	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-10-24 10:19 [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages Petre Pircalabu
@ 2017-11-20  9:35 ` Petre Ovidiu PIRCALABU
  2017-11-20 11:39   ` Jan Beulich
  2017-12-08 12:18 ` Jan Beulich
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 26+ messages in thread
From: Petre Ovidiu PIRCALABU @ 2017-11-20  9:35 UTC (permalink / raw)
  To: xen-devel
  Cc: sstabellini, wei.liu2, rcojocaru, konrad.wilk, George.Dunlap,
	andrew.cooper3, ian.jackson, tim, jbeulich

On Ma, 2017-10-24 at 13:19 +0300, Petre Pircalabu wrote:
> From: Razvan Cojocaru <rcojocaru@bitdefender.com>
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2m subsystem, which could only set page restrictions for one
> page at a time. This patch addresses the gap.
>
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as
> opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access
> counterpart (and
> hence with the original altp2m design, where domains are allowed -
> with the
> proper altp2m access rights - to alter these settings), in the
> absence of an
> official position on the issue from the original altp2m designers.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
>
Hello,

Are there still any outstanding issues with this patch?

Many thanks,
Petre

________________________
This email was scanned by Bitdefender
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-11-20  9:35 ` Petre Ovidiu PIRCALABU
@ 2017-11-20 11:39   ` Jan Beulich
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Beulich @ 2017-11-20 11:39 UTC (permalink / raw)
  To: Petre Ovidiu PIRCALABU, xen-devel
  Cc: sstabellini, wei.liu2, rcojocaru, konrad.wilk, George.Dunlap,
	andrew.cooper3, ian.jackson, tim

>>> On 20.11.17 at 10:35, <ppircalabu@bitdefender.com> wrote:
> On Ma, 2017-10-24 at 13:19 +0300, Petre Pircalabu wrote:
>> From: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>
>> For the default EPT view we have xc_set_mem_access_multi(), which
>> is able to set an array of pages to an array of access rights with
>> a single hypercall. However, this functionality was lacking for the
>> altp2m subsystem, which could only set page restrictions for one
>> page at a time. This patch addresses the gap.
>>
>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as
>> opposed to a
>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access
>> counterpart (and
>> hence with the original altp2m design, where domains are allowed -
>> with the
>> proper altp2m access rights - to alter these settings), in the
>> absence of an
>> official position on the issue from the original altp2m designers.
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
>> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>
> 
> Are there still any outstanding issues with this patch?

I for one don't know - I simply did't get around to look at it yet.
The tree's still frozen right now anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-10-24 10:19 [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages Petre Pircalabu
  2017-11-20  9:35 ` Petre Ovidiu PIRCALABU
@ 2017-12-08 12:18 ` Jan Beulich
  2017-12-08 12:42   ` Razvan Cojocaru
  2017-12-11 16:18 ` George Dunlap
  2017-12-11 16:22 ` George Dunlap
  3 siblings, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2017-12-08 12:18 UTC (permalink / raw)
  To: Petre Pircalabu
  Cc: tim, sstabellini, wei.liu2, Razvan Cojocaru, George.Dunlap,
	andrew.cooper3, ian.jackson, xen-devel

>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access rights - to alter these settings), in the absence of an
> official position on the issue from the original altp2m designers.

I continue to disagree with this reasoning. I'm afraid I'm not really
willing to allow widening the badness, unless altp2m was formally
documented security-unsupported.

> +int xc_altp2m_set_mem_access_multi(xc_interface *xch, uint32_t domid,
> +                                   uint16_t view_id, uint8_t *access,
> +                                   uint64_t *pages, uint32_t nr)
> +{
> +    int rc;
> +
> +    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +    DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +    DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
> +                             XC_HYPERCALL_BUFFER_BOUNCE_IN);

This is confusing: Why "* sizeof()" in the latter expression, but not
in the former. It would anyway be better to use sizeof(*pages) (and
then also sizeof(*access)) to clearly make the connection.

> @@ -4568,6 +4571,37 @@ static int do_altp2m_op(
>                                      a.u.set_mem_access.view);
>          break;
>  
> +    case HVMOP_altp2m_set_mem_access_multi:
> +        if ( a.u.set_mem_access_multi.pad ||
> +             a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr )
> +        {
> +            rc = -EINVAL;
> +            break;
> +        }

Just like in a number of other recent cases: This operation should not
fail when .nr is zero. Yet as per above it will.

> +static int compat_altp2m_op(
> +    XEN_GUEST_HANDLE_PARAM(void) arg)
> +{
> +    int rc = 0;
> +    struct compat_hvm_altp2m_op a;
> +    union
> +    {
> +        XEN_GUEST_HANDLE_PARAM(void) hnd;
> +        struct xen_hvm_altp2m_op *altp2m_op;
> +    } nat;
> +
> +    if ( !hvm_altp2m_supported() )
> +        return -EOPNOTSUPP;
> +
> +    if ( copy_from_guest(&a, arg, 1) )
> +        return -EFAULT;
> +
> +    if ( a.pad1 || a.pad2 ||
> +         (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
> +        return -EINVAL;
> +
> +    set_xen_guest_handle(nat.hnd, COMPAT_ARG_XLAT_VIRT_BASE);
> +
> +    switch ( a.cmd )
> +    {
> +    case HVMOP_altp2m_set_mem_access_multi:
> +#define XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list(_d_, _s_); \
> +        guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
> +#define XLAT_hvm_altp2m_set_mem_access_multi_HNDL_access_list(_d_, _s_); \
> +        guest_from_compat_handle((_d_)->access_list, (_s_)->access_list)
> +        
> XLAT_hvm_altp2m_set_mem_access_multi(&nat.altp2m_op->u.set_mem_access_multi,
> +                                             &a.u.set_mem_access_multi);
> +#undef XLAT_hvm_altp2m_set_mem_access_multi_HNDL_pfn_list
> +#undef XLAT_hvm_altp2m_set_mem_access_multi_HNDL_access_list
> +        break;
> +    default:

Blank line between individual case blocks please (also below).

> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -28,6 +28,7 @@ headers-$(CONFIG_X86)     += compat/arch-x86/xen.h
>  headers-$(CONFIG_X86)     += compat/arch-x86/xen-$(compat-arch-y).h
>  headers-$(CONFIG_X86)     += compat/hvm/hvm_vcpu.h
>  headers-$(CONFIG_X86)     += compat/hvm/dm_op.h
> +headers-$(CONFIG_X86)     += compat/hvm/hvm_op.h

I realize the dm_op.h insertion was already to the wrong spot, but
please let's not make things worse: Anywhere that order doesn't
otherwise matter, please sort alphabetically, to prevent everyone
adding to the end (and hence increasing the risk of patch conflicts).

> @@ -237,6 +246,20 @@ struct xen_hvm_altp2m_set_mem_access {
>  typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
>  
> +struct xen_hvm_altp2m_set_mem_access_multi {
> +    /* view */
> +    uint16_t view;
> +    uint16_t pad;
> +    /* Number of pages */
> +    uint32_t nr;
> +    /* Used for continuation purposes */
> +    uint64_t opaque;

The comment should also state that this needs to be set to zero
upon initial invocation.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-08 12:18 ` Jan Beulich
@ 2017-12-08 12:42   ` Razvan Cojocaru
  2017-12-08 16:56     ` Tamas K Lengyel
  2017-12-11  9:14     ` Jan Beulich
  0 siblings, 2 replies; 26+ messages in thread
From: Razvan Cojocaru @ 2017-12-08 12:42 UTC (permalink / raw)
  To: Jan Beulich, Petre Pircalabu
  Cc: tim, sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
	ian.jackson, xen-devel, Tamas K Lengyel

On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
>> hence with the original altp2m design, where domains are allowed - with the
>> proper altp2m access rights - to alter these settings), in the absence of an
>> official position on the issue from the original altp2m designers.
> 
> I continue to disagree with this reasoning. I'm afraid I'm not really
> willing to allow widening the badness, unless altp2m was formally
> documented security-unsupported.

Going the DOMCTL route here would have been the (much easier) solution,
and in fact, as stated before, there has been an attempt to do so -
however, IIRC Andrew has insisted that we should take care to use
consistent access privilege across altp2m operations.

This was followed by a lengthy xen-devel discussion and several
unsuccessful attempts to obtain an official position from the original
contributors, at which point (after several months), as also discussed
at the Xen Developer Summit in Budapest, we decided to press on in the
direction that had seemed the most compatible with the original altp2m
design. (Please correct me if I'm misremembering or misunderstanding
something.)

So at this point it looks like we're stuck again: we're happy to go in
any direction the maintainers decide is the best, but we do need to
decide on one.

FWIW, Tamas (CC added) has added code to restrict where altp2m calls can
come from (although that's not XSM code).

Please let us know how to proceed.

>> +int xc_altp2m_set_mem_access_multi(xc_interface *xch, uint32_t domid,
>> +                                   uint16_t view_id, uint8_t *access,
>> +                                   uint64_t *pages, uint32_t nr)
>> +{
>> +    int rc;
>> +
>> +    DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
>> +    DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
>> +    DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
>> +                             XC_HYPERCALL_BUFFER_BOUNCE_IN);
> 
> This is confusing: Why "* sizeof()" in the latter expression, but not
> in the former. It would anyway be better to use sizeof(*pages) (and
> then also sizeof(*access)) to clearly make the connection.

I've opted for less clutter here, since of course sizeof(uint8_t) == 1,
so nr == nr * sizeof(uint8_t). But we're happy to make the change, it
will indeed make the code clearer.

>> @@ -4568,6 +4571,37 @@ static int do_altp2m_op(
>>                                      a.u.set_mem_access.view);
>>          break;
>>  
>> +    case HVMOP_altp2m_set_mem_access_multi:
>> +        if ( a.u.set_mem_access_multi.pad ||
>> +             a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr )
>> +        {
>> +            rc = -EINVAL;
>> +            break;
>> +        }
> 
> Just like in a number of other recent cases: This operation should not
> fail when .nr is zero. Yet as per above it will.

We'll test that .nr != 0 before the >= comparison.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-08 12:42   ` Razvan Cojocaru
@ 2017-12-08 16:56     ` Tamas K Lengyel
  2017-12-11  9:14     ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: Tamas K Lengyel @ 2017-12-08 16:56 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Petre Pircalabu, tim, Stefano Stabellini, wei.liu2,
	George Dunlap, Andrew Cooper, Ian Jackson, Xen-devel,
	Jan Beulich

On Fri, Dec 8, 2017 at 5:42 AM, Razvan Cojocaru
<rcojocaru@bitdefender.com> wrote:
> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
>>> hence with the original altp2m design, where domains are allowed - with the
>>> proper altp2m access rights - to alter these settings), in the absence of an
>>> official position on the issue from the original altp2m designers.
>>
>> I continue to disagree with this reasoning. I'm afraid I'm not really
>> willing to allow widening the badness, unless altp2m was formally
>> documented security-unsupported.
>
> Going the DOMCTL route here would have been the (much easier) solution,
> and in fact, as stated before, there has been an attempt to do so -
> however, IIRC Andrew has insisted that we should take care to use
> consistent access privilege across altp2m operations.
>
> This was followed by a lengthy xen-devel discussion and several
> unsuccessful attempts to obtain an official position from the original
> contributors, at which point (after several months), as also discussed
> at the Xen Developer Summit in Budapest, we decided to press on in the
> direction that had seemed the most compatible with the original altp2m
> design. (Please correct me if I'm misremembering or misunderstanding
> something.)
>
> So at this point it looks like we're stuck again: we're happy to go in
> any direction the maintainers decide is the best, but we do need to
> decide on one.
>
> FWIW, Tamas (CC added) has added code to restrict where altp2m calls can
> come from (although that's not XSM code).
>
> Please let us know how to proceed.

I personally don't see anything wrong adding this as an HVMOP. The
original idea with altp2m was that it will be used with VMFUNC where
there is a guest kernel-level component that is trusted and
coordinates with the hypervisor. With the setting I've added to the
altp2m config it is now possible to limit whether the guest actually
has the right to use the HVMOP or not, even without XSM. So adding
this doesn't really mean its "widening the badness", it's configurable
and could very well be appropriate depending on the use-case.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-08 12:42   ` Razvan Cojocaru
  2017-12-08 16:56     ` Tamas K Lengyel
@ 2017-12-11  9:14     ` Jan Beulich
  2017-12-11 11:06       ` Andrew Cooper
  1 sibling, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2017-12-11  9:14 UTC (permalink / raw)
  To: Petre Pircalabu, Razvan Cojocaru, andrew.cooper3
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	xen-devel, Tamas K Lengyel

>>> On 08.12.17 at 13:42, <rcojocaru@bitdefender.com> wrote:
> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
>>> hence with the original altp2m design, where domains are allowed - with the
>>> proper altp2m access rights - to alter these settings), in the absence of an
>>> official position on the issue from the original altp2m designers.
>> 
>> I continue to disagree with this reasoning. I'm afraid I'm not really
>> willing to allow widening the badness, unless altp2m was formally
>> documented security-unsupported.
> 
> Going the DOMCTL route here would have been the (much easier) solution,
> and in fact, as stated before, there has been an attempt to do so -
> however, IIRC Andrew has insisted that we should take care to use
> consistent access privilege across altp2m operations.

Andrew, is that the case (I don't recall anything like that)?

> This was followed by a lengthy xen-devel discussion and several
> unsuccessful attempts to obtain an official position from the original
> contributors, at which point (after several months), as also discussed
> at the Xen Developer Summit in Budapest, we decided to press on in the
> direction that had seemed the most compatible with the original altp2m
> design. (Please correct me if I'm misremembering or misunderstanding
> something.)
> 
> So at this point it looks like we're stuck again: we're happy to go in
> any direction the maintainers decide is the best, but we do need to
> decide on one.
> 
> FWIW, Tamas (CC added) has added code to restrict where altp2m calls can
> come from (although that's not XSM code).
> 
> Please let us know how to proceed.

I've given my suggestion already: Now that we have SUPPORT.md,
submit a patch to add altp2m there (not sure if it was in the part of
George's series that was left out for the moment), stating it's
security unsupported. With that's I still wouldn't like the addition by
this patch, but I also wouldn't object to this widening of an already
bad situation anymore: Anyone wanting to alter that support status
would first need to deal with the too wide exposure of some of the
operations.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11  9:14     ` Jan Beulich
@ 2017-12-11 11:06       ` Andrew Cooper
  2017-12-11 12:12         ` Jan Beulich
  0 siblings, 1 reply; 26+ messages in thread
From: Andrew Cooper @ 2017-12-11 11:06 UTC (permalink / raw)
  To: Jan Beulich, Petre Pircalabu, Razvan Cojocaru
  Cc: sstabellini, wei.liu2, George.Dunlap, tim, ian.jackson,
	xen-devel, Tamas K Lengyel

On 11/12/17 09:14, Jan Beulich wrote:
>>>> On 08.12.17 at 13:42, <rcojocaru@bitdefender.com> wrote:
>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
>>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
>>>> hence with the original altp2m design, where domains are allowed - with the
>>>> proper altp2m access rights - to alter these settings), in the absence of an
>>>> official position on the issue from the original altp2m designers.
>>> I continue to disagree with this reasoning. I'm afraid I'm not really
>>> willing to allow widening the badness, unless altp2m was formally
>>> documented security-unsupported.
>> Going the DOMCTL route here would have been the (much easier) solution,
>> and in fact, as stated before, there has been an attempt to do so -
>> however, IIRC Andrew has insisted that we should take care to use
>> consistent access privilege across altp2m operations.
> Andrew, is that the case (I don't recall anything like that)?

My suggestion was that we don't break usecases.  The Intel usecase
specifically is for an in-guest entity to have full control of all
altp2m functionality, and this is fine (security wise) when permitted to
do so by the toolstack.

~Andrew

>
>> This was followed by a lengthy xen-devel discussion and several
>> unsuccessful attempts to obtain an official position from the original
>> contributors, at which point (after several months), as also discussed
>> at the Xen Developer Summit in Budapest, we decided to press on in the
>> direction that had seemed the most compatible with the original altp2m
>> design. (Please correct me if I'm misremembering or misunderstanding
>> something.)
>>
>> So at this point it looks like we're stuck again: we're happy to go in
>> any direction the maintainers decide is the best, but we do need to
>> decide on one.
>>
>> FWIW, Tamas (CC added) has added code to restrict where altp2m calls can
>> come from (although that's not XSM code).
>>
>> Please let us know how to proceed.
> I've given my suggestion already: Now that we have SUPPORT.md,
> submit a patch to add altp2m there (not sure if it was in the part of
> George's series that was left out for the moment), stating it's
> security unsupported. With that's I still wouldn't like the addition by
> this patch, but I also wouldn't object to this widening of an already
> bad situation anymore: Anyone wanting to alter that support status
> would first need to deal with the too wide exposure of some of the
> operations.
>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 11:06       ` Andrew Cooper
@ 2017-12-11 12:12         ` Jan Beulich
  2017-12-11 12:50           ` George Dunlap
  0 siblings, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2017-12-11 12:12 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Petre Pircalabu, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, tim, ian.jackson, xen-devel, Tamas K Lengyel

>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
> On 11/12/17 09:14, Jan Beulich wrote:
>>>>> On 08.12.17 at 13:42, <rcojocaru@bitdefender.com> wrote:
>>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>>>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
>>>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart 
> (and
>>>>> hence with the original altp2m design, where domains are allowed - with the
>>>>> proper altp2m access rights - to alter these settings), in the absence of an
>>>>> official position on the issue from the original altp2m designers.
>>>> I continue to disagree with this reasoning. I'm afraid I'm not really
>>>> willing to allow widening the badness, unless altp2m was formally
>>>> documented security-unsupported.
>>> Going the DOMCTL route here would have been the (much easier) solution,
>>> and in fact, as stated before, there has been an attempt to do so -
>>> however, IIRC Andrew has insisted that we should take care to use
>>> consistent access privilege across altp2m operations.
>> Andrew, is that the case (I don't recall anything like that)?
> 
> My suggestion was that we don't break usecases.  The Intel usecase
> specifically is for an in-guest entity to have full control of all
> altp2m functionality, and this is fine (security wise) when permitted to
> do so by the toolstack.

IOW you mean that such guests would be considered "trusted", i.e.
whatever bad they can do is by definition not a security concern.
If so, that's fine of course, provided the default mode is secure
(which it looks like it is by virtue of altp2m being disabled altogether
by default). Yet I don't think I know of a place where this is being
spelled out.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 12:12         ` Jan Beulich
@ 2017-12-11 12:50           ` George Dunlap
  2017-12-11 13:36             ` Jan Beulich
  0 siblings, 1 reply; 26+ messages in thread
From: George Dunlap @ 2017-12-11 12:50 UTC (permalink / raw)
  To: Jan Beulich, Andrew Cooper
  Cc: Petre Pircalabu, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, tim, ian.jackson, xen-devel, Tamas K Lengyel

On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>> On 11/12/17 09:14, Jan Beulich wrote:
>>>>>> On 08.12.17 at 13:42, <rcojocaru@bitdefender.com> wrote:
>>>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>>>>>> On 24.10.17 at 12:19, <ppircalabu@bitdefender.com> wrote:
>>>>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
>>>>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart 
>> (and
>>>>>> hence with the original altp2m design, where domains are allowed - with the
>>>>>> proper altp2m access rights - to alter these settings), in the absence of an
>>>>>> official position on the issue from the original altp2m designers.
>>>>> I continue to disagree with this reasoning. I'm afraid I'm not really
>>>>> willing to allow widening the badness, unless altp2m was formally
>>>>> documented security-unsupported.
>>>> Going the DOMCTL route here would have been the (much easier) solution,
>>>> and in fact, as stated before, there has been an attempt to do so -
>>>> however, IIRC Andrew has insisted that we should take care to use
>>>> consistent access privilege across altp2m operations.
>>> Andrew, is that the case (I don't recall anything like that)?
>>
>> My suggestion was that we don't break usecases.  The Intel usecase
>> specifically is for an in-guest entity to have full control of all
>> altp2m functionality, and this is fine (security wise) when permitted to
>> do so by the toolstack.
> 
> IOW you mean that such guests would be considered "trusted", i.e.
> whatever bad they can do is by definition not a security concern.

I'm not sure what you mean by "trusted".  If implemented correctly,
altp2m and mem_access shouldn't give the guest any more permissions than
it has already.  The main risk would be if there were bugs in the
functionality that allowed security issues.

You argued that we should keep PV linear pagetables, before knowing that
NetBSD used them, in spite of having discovered two *actual*
vulnerabilities in the implementation.  I don't really see how this is
different.

We obviously need to go though the code with a fine-toothed comb before
we say that we'll give security support to the mode where we allow a
guest agent to modify altp2m access.  Since we can control whether this
functionality is exposed to the guest or not, we can specify whether we
provide security support for toolstack altp2m access vs guest altp2m access.

> If so, that's fine of course, provided the default mode is secure
> (which it looks like it is by virtue of altp2m being disabled altogether
> by default). Yet I don't think I know of a place where this is being
> spelled out.

SUPPORT.md has "Alternative p2m" listed as "tech preview", which would
mean "not security supported".  Maybe that needs an "altp2m" tag
somewhere so it's easier to grep for?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 12:50           ` George Dunlap
@ 2017-12-11 13:36             ` Jan Beulich
  2017-12-11 14:46               ` Razvan Cojocaru
  2017-12-11 14:50               ` George Dunlap
  0 siblings, 2 replies; 26+ messages in thread
From: Jan Beulich @ 2017-12-11 13:36 UTC (permalink / raw)
  To: George Dunlap
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, Andrew Cooper, ian.jackson, xen-devel,
	Tamas K Lengyel

>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>> My suggestion was that we don't break usecases.  The Intel usecase
>>> specifically is for an in-guest entity to have full control of all
>>> altp2m functionality, and this is fine (security wise) when permitted to
>>> do so by the toolstack.
>> 
>> IOW you mean that such guests would be considered "trusted", i.e.
>> whatever bad they can do is by definition not a security concern.
> 
> I'm not sure what you mean by "trusted".  If implemented correctly,
> altp2m and mem_access shouldn't give the guest any more permissions than
> it has already.  The main risk would be if there were bugs in the
> functionality that allowed security issues.

Hmm, maybe I'm mis-reading the code, but
mem_access.c:set_mem_access() looks to be using the requested
access rights verbatim, i.e. without applying tool stack imposed
restrictions (hypervisor ones look to be honored by deriving
base permissions from the p2m type first).

> You argued that we should keep PV linear pagetables, before knowing that
> NetBSD used them, in spite of having discovered two *actual*
> vulnerabilities in the implementation.  I don't really see how this is
> different.

It's quite the opposite to me - I don't see the similarity. On this
thread we're talking about new functionality, and how far to
expose it. PV linear page tables had been there (and considered
supported) for years, so removing the functionality or even only
calling it unsupported all of the sudden didn't seem right at all.
Even for altp2m as a whole I don't think it's mature enough for
us to not be able to declare parts of it not security supported.

>> If so, that's fine of course, provided the default mode is secure
>> (which it looks like it is by virtue of altp2m being disabled altogether
>> by default). Yet I don't think I know of a place where this is being
>> spelled out.
> 
> SUPPORT.md has "Alternative p2m" listed as "tech preview", which would
> mean "not security supported".  Maybe that needs an "altp2m" tag
> somewhere so it's easier to grep for?

Ah - indeed I had searched for altp2m only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 13:36             ` Jan Beulich
@ 2017-12-11 14:46               ` Razvan Cojocaru
  2017-12-11 14:51                 ` George Dunlap
  2017-12-11 15:03                 ` Jan Beulich
  2017-12-11 14:50               ` George Dunlap
  1 sibling, 2 replies; 26+ messages in thread
From: Razvan Cojocaru @ 2017-12-11 14:46 UTC (permalink / raw)
  To: Jan Beulich, George Dunlap
  Cc: Petre Pircalabu, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, tim, xen-devel, Tamas K Lengyel, ian.jackson

On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>> specifically is for an in-guest entity to have full control of all
>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>> do so by the toolstack.
>>>
>>> IOW you mean that such guests would be considered "trusted", i.e.
>>> whatever bad they can do is by definition not a security concern.
>>
>> I'm not sure what you mean by "trusted".  If implemented correctly,
>> altp2m and mem_access shouldn't give the guest any more permissions than
>> it has already.  The main risk would be if there were bugs in the
>> functionality that allowed security issues.
> 
> Hmm, maybe I'm mis-reading the code, but
> mem_access.c:set_mem_access() looks to be using the requested
> access rights verbatim, i.e. without applying tool stack imposed
> restrictions (hypervisor ones look to be honored by deriving
> base permissions from the p2m type first).

Quite likely I'm not grasping the full meaning of your objection,
however the added code is merely another interface to already existing
core code - so while admittedly there's room for improvement for the EPT
code below it, this patch really only extends the scope of altp2m's
existing version of set_mem_access() (which currently works on a single
page). In that, it at least doesn't seem to make things worse (it's
really just an optimization - whatever badness this code can cause with
a single call, can already be achieved exactly with a sequence of
xc_altp2m_set_mem_access() calls).


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 13:36             ` Jan Beulich
  2017-12-11 14:46               ` Razvan Cojocaru
@ 2017-12-11 14:50               ` George Dunlap
  2017-12-11 14:58                 ` Jan Beulich
  1 sibling, 1 reply; 26+ messages in thread
From: George Dunlap @ 2017-12-11 14:50 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, Andrew Cooper, ian.jackson, xen-devel,
	Tamas K Lengyel

On 12/11/2017 01:36 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>> specifically is for an in-guest entity to have full control of all
>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>> do so by the toolstack.
>>>
>>> IOW you mean that such guests would be considered "trusted", i.e.
>>> whatever bad they can do is by definition not a security concern.
>>
>> I'm not sure what you mean by "trusted".  If implemented correctly,
>> altp2m and mem_access shouldn't give the guest any more permissions than
>> it has already.  The main risk would be if there were bugs in the
>> functionality that allowed security issues.
> 
> Hmm, maybe I'm mis-reading the code, but
> mem_access.c:set_mem_access() looks to be using the requested
> access rights verbatim, i.e. without applying tool stack imposed
> restrictions (hypervisor ones look to be honored by deriving
> base permissions from the p2m type first).

Right, so one thing that would need to be fixed is to enumerate which
things should work with what.  At the moment it looks like toolstack
mem_access functionality is simply incompatible with altp2m mem_access
functionality.  If you want to use toolstack mem_access, don't enable
guest altp2m mem_access.

If they were both needed to run at the same time, we could 1) prevent
the guest from modifying the "host p2m" (altp2m index 0) and 2) make
sure the altp2m entries were at least as strict as the host p2m entries.

>> You argued that we should keep PV linear pagetables, before knowing that
>> NetBSD used them, in spite of having discovered two *actual*
>> vulnerabilities in the implementation.  I don't really see how this is
>> different.
> 
> It's quite the opposite to me - I don't see the similarity. On this
> thread we're talking about new functionality, and how far to
> expose it. PV linear page tables had been there (and considered
> supported) for years, so removing the functionality or even only
> calling it unsupported all of the sudden didn't seem right at all.

Well the idea of calling it unsupported was assuming that there weren't
many people using it; finding out that NetWare, and in particular
NetBSD, still used it changes the situation quite a bit.

What I remember you actually saying at the time was, "We have
functionality already, I don't see why we don't make it secure rather
than removing it."  The same kind of argument would seem to apply here:
We have functionality that allows a guest agent to manipulate its altp2m
access rights; why we don't make it secure rather than removing it?

I certainly agree we shouldn't call it security supported until it's had
a thorough audit; and I wouldn't do that work unless there was someone
who actually wanted that support.  But leaving the code in a state that
could be given security support whenever someone wants to pick it up
makes some sense (as long as it doesn't open up new attacks for guests
not using that feature).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 14:46               ` Razvan Cojocaru
@ 2017-12-11 14:51                 ` George Dunlap
  2017-12-11 14:55                   ` George Dunlap
  2017-12-11 15:05                   ` Jan Beulich
  2017-12-11 15:03                 ` Jan Beulich
  1 sibling, 2 replies; 26+ messages in thread
From: George Dunlap @ 2017-12-11 14:51 UTC (permalink / raw)
  To: Razvan Cojocaru, Jan Beulich
  Cc: Petre Pircalabu, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, tim, xen-devel, Tamas K Lengyel, ian.jackson

On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>> specifically is for an in-guest entity to have full control of all
>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>> do so by the toolstack.
>>>>
>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>> whatever bad they can do is by definition not a security concern.
>>>
>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>> it has already.  The main risk would be if there were bugs in the
>>> functionality that allowed security issues.
>>
>> Hmm, maybe I'm mis-reading the code, but
>> mem_access.c:set_mem_access() looks to be using the requested
>> access rights verbatim, i.e. without applying tool stack imposed
>> restrictions (hypervisor ones look to be honored by deriving
>> base permissions from the p2m type first).
> 
> Quite likely I'm not grasping the full meaning of your objection,
> however the added code is merely another interface to already existing
> core code - so while admittedly there's room for improvement for the EPT
> code below it, this patch really only extends the scope of altp2m's
> existing version of set_mem_access() (which currently works on a single
> page). In that, it at least doesn't seem to make things worse (it's
> really just an optimization - whatever badness this code can cause with
> a single call, can already be achieved exactly with a sequence of
> xc_altp2m_set_mem_access() calls).

I think Jan was saying that he would ideally like to remove *all* guest
access to altp2m functionality, even what's currently there.  The more
extra features we make available to guests, the harder it will be in the
future to argue to remove it all.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 14:51                 ` George Dunlap
@ 2017-12-11 14:55                   ` George Dunlap
  2017-12-11 15:05                   ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: George Dunlap @ 2017-12-11 14:55 UTC (permalink / raw)
  To: Razvan Cojocaru, Jan Beulich
  Cc: Petre Pircalabu, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, tim, xen-devel, Tamas K Lengyel, ian.jackson

On 12/11/2017 02:51 PM, George Dunlap wrote:
> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>>> specifically is for an in-guest entity to have full control of all
>>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>>> do so by the toolstack.
>>>>>
>>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>>> whatever bad they can do is by definition not a security concern.
>>>>
>>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>>> it has already.  The main risk would be if there were bugs in the
>>>> functionality that allowed security issues.
>>>
>>> Hmm, maybe I'm mis-reading the code, but
>>> mem_access.c:set_mem_access() looks to be using the requested
>>> access rights verbatim, i.e. without applying tool stack imposed
>>> restrictions (hypervisor ones look to be honored by deriving
>>> base permissions from the p2m type first).
>>
>> Quite likely I'm not grasping the full meaning of your objection,
>> however the added code is merely another interface to already existing
>> core code - so while admittedly there's room for improvement for the EPT
>> code below it, this patch really only extends the scope of altp2m's
>> existing version of set_mem_access() (which currently works on a single
>> page). In that, it at least doesn't seem to make things worse (it's
>> really just an optimization - whatever badness this code can cause with
>> a single call, can already be achieved exactly with a sequence of
>> xc_altp2m_set_mem_access() calls).
> 
> I think Jan was saying that he would ideally like to remove *all* guest
> access to altp2m functionality, even what's currently there.  The more
> extra features we make available to guests, the harder it will be in the
> future to argue to remove it all.

...so the real question we're trying to decide here is: Should the guest
be allowed access to altp2m functionality -- in particular the
mem_access functionality?  If so, then your new hypercall should
probably be HVMOP (as Andy suggested).  If not, then it should be
something else, and someone should change the existing HVMOP to a DOMCTL.

Andy and Tamas have argued that the 'guest agent' is an important use
case and should be supported, and I'm inclined to agree with them.  Jan
seems partly to be afraid that the guest altp2m mem_access functionality
is *currently* not mature enough to be security supported; and partly to
be afraid that it can never be mature enough to be security supported.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 14:50               ` George Dunlap
@ 2017-12-11 14:58                 ` Jan Beulich
  2017-12-11 15:38                   ` George Dunlap
  0 siblings, 1 reply; 26+ messages in thread
From: Jan Beulich @ 2017-12-11 14:58 UTC (permalink / raw)
  To: George Dunlap
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, Andrew Cooper, ian.jackson, xen-devel,
	Tamas K Lengyel

>>> On 11.12.17 at 15:50, <george.dunlap@citrix.com> wrote:
> On 12/11/2017 01:36 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>> You argued that we should keep PV linear pagetables, before knowing that
>>> NetBSD used them, in spite of having discovered two *actual*
>>> vulnerabilities in the implementation.  I don't really see how this is
>>> different.
>> 
>> It's quite the opposite to me - I don't see the similarity. On this
>> thread we're talking about new functionality, and how far to
>> expose it. PV linear page tables had been there (and considered
>> supported) for years, so removing the functionality or even only
>> calling it unsupported all of the sudden didn't seem right at all.
> 
> Well the idea of calling it unsupported was assuming that there weren't
> many people using it; finding out that NetWare, and in particular
> NetBSD, still used it changes the situation quite a bit.
> 
> What I remember you actually saying at the time was, "We have
> functionality already, I don't see why we don't make it secure rather
> than removing it."  The same kind of argument would seem to apply here:
> We have functionality that allows a guest agent to manipulate its altp2m
> access rights; why we don't make it secure rather than removing it?

That's a good option, but the patch here doesn't do so. Instead it
increases the amount of code that will later need auditing /
altering.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 14:46               ` Razvan Cojocaru
  2017-12-11 14:51                 ` George Dunlap
@ 2017-12-11 15:03                 ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: Jan Beulich @ 2017-12-11 15:03 UTC (permalink / raw)
  To: Razvan Cojocaru
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, ian.jackson, George Dunlap, xen-devel,
	Tamas K Lengyel

>>> On 11.12.17 at 15:46, <rcojocaru@bitdefender.com> wrote:
> Quite likely I'm not grasping the full meaning of your objection,
> however the added code is merely another interface to already existing
> core code - so while admittedly there's room for improvement for the EPT
> code below it, this patch really only extends the scope of altp2m's
> existing version of set_mem_access() (which currently works on a single
> page). In that, it at least doesn't seem to make things worse (it's
> really just an optimization - whatever badness this code can cause with
> a single call, can already be achieved exactly with a sequence of
> xc_altp2m_set_mem_access() calls).

That's true. Yet as just said in reply to George, any addition (like the
one here) increases the amount of code needing auditing (and
perhaps changing) before it could reach fully supported state. This
is what I dislike. However, I've also said earlier that I wouldn't stand
in the way of doing additions like the one here as long as the code
is properly documented as security unsupported. As you've certainly
seen, George has meanwhile pointed out that this is already the case.
Hence while I won't ack any extension of the badness, I also won't
argue against it (at least not in a way preventing the code from
going in).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 14:51                 ` George Dunlap
  2017-12-11 14:55                   ` George Dunlap
@ 2017-12-11 15:05                   ` Jan Beulich
  2017-12-11 15:54                     ` George Dunlap
  2017-12-11 16:00                     ` Tamas K Lengyel
  1 sibling, 2 replies; 26+ messages in thread
From: Jan Beulich @ 2017-12-11 15:05 UTC (permalink / raw)
  To: Razvan Cojocaru, George Dunlap
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, ian.jackson, xen-devel, Tamas K Lengyel

>>> On 11.12.17 at 15:51, <george.dunlap@citrix.com> wrote:
> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>>> specifically is for an in-guest entity to have full control of all
>>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>>> do so by the toolstack.
>>>>>
>>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>>> whatever bad they can do is by definition not a security concern.
>>>>
>>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>>> it has already.  The main risk would be if there were bugs in the
>>>> functionality that allowed security issues.
>>>
>>> Hmm, maybe I'm mis-reading the code, but
>>> mem_access.c:set_mem_access() looks to be using the requested
>>> access rights verbatim, i.e. without applying tool stack imposed
>>> restrictions (hypervisor ones look to be honored by deriving
>>> base permissions from the p2m type first).
>> 
>> Quite likely I'm not grasping the full meaning of your objection,
>> however the added code is merely another interface to already existing
>> core code - so while admittedly there's room for improvement for the EPT
>> code below it, this patch really only extends the scope of altp2m's
>> existing version of set_mem_access() (which currently works on a single
>> page). In that, it at least doesn't seem to make things worse (it's
>> really just an optimization - whatever badness this code can cause with
>> a single call, can already be achieved exactly with a sequence of
>> xc_altp2m_set_mem_access() calls).
> 
> I think Jan was saying that he would ideally like to remove *all* guest
> access to altp2m functionality, even what's currently there.  The more
> extra features we make available to guests, the harder it will be in the
> future to argue to remove it all.

With one slight correction: all _uncontrolled_ access is what I'd like
to see removed. Right now this could arguably indeed mean all
access, as it is all uncontrolled (afaict).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 14:58                 ` Jan Beulich
@ 2017-12-11 15:38                   ` George Dunlap
  0 siblings, 0 replies; 26+ messages in thread
From: George Dunlap @ 2017-12-11 15:38 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, Andrew Cooper, ian.jackson, xen-devel,
	Tamas K Lengyel

On 12/11/2017 02:58 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 15:50, <george.dunlap@citrix.com> wrote:
>> On 12/11/2017 01:36 PM, Jan Beulich wrote:
>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>> You argued that we should keep PV linear pagetables, before knowing that
>>>> NetBSD used them, in spite of having discovered two *actual*
>>>> vulnerabilities in the implementation.  I don't really see how this is
>>>> different.
>>>
>>> It's quite the opposite to me - I don't see the similarity. On this
>>> thread we're talking about new functionality, and how far to
>>> expose it. PV linear page tables had been there (and considered
>>> supported) for years, so removing the functionality or even only
>>> calling it unsupported all of the sudden didn't seem right at all.
>>
>> Well the idea of calling it unsupported was assuming that there weren't
>> many people using it; finding out that NetWare, and in particular
>> NetBSD, still used it changes the situation quite a bit.
>>
>> What I remember you actually saying at the time was, "We have
>> functionality already, I don't see why we don't make it secure rather
>> than removing it."  The same kind of argument would seem to apply here:
>> We have functionality that allows a guest agent to manipulate its altp2m
>> access rights; why we don't make it secure rather than removing it?
> 
> That's a good option, but the patch here doesn't do so. Instead it
> increases the amount of code that will later need auditing /
> altering.

Right, but that's because their goal isn't to get guest support working.
 It doesn't sound like they particularly care about HVMOP / DOMCTL at
all; rather, it's Andy who has insisted that it be extended in line with
the current interface, for such a time as someone wants to use the guest
altp2m hypercalls.

First of all, I agree with Andy, that we should make interfaces
consistent.  If we have altp2m_set_mem_access is an HVMOP, then
altp2m_set_mem_access_multi should be an HVMOP.  If on the other hand we
don't want altp2m_set_mem_access_multi as an HVMOP, then we should
change altp2m_set_mem_access into a DOMCTL as well.

At the moment I prefer the first option, because one of Xen's historical
"niches" is support for quirky additional security features.  It seems
to me that having a functioning, but non-audited / security supported
feature in place, such that people can come along and fix it up (rather
than implementing it from scratch) puts us in a better position --
providing, of course, that having the functionality available in "tech
preview" status doesn't add significant risk to normal users.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 15:05                   ` Jan Beulich
@ 2017-12-11 15:54                     ` George Dunlap
  2017-12-11 15:58                       ` Razvan Cojocaru
  2017-12-11 16:24                       ` Jan Beulich
  2017-12-11 16:00                     ` Tamas K Lengyel
  1 sibling, 2 replies; 26+ messages in thread
From: George Dunlap @ 2017-12-11 15:54 UTC (permalink / raw)
  To: Jan Beulich, Razvan Cojocaru
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, ian.jackson, xen-devel, Tamas K Lengyel

On 12/11/2017 03:05 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 15:51, <george.dunlap@citrix.com> wrote:
>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>>>> specifically is for an in-guest entity to have full control of all
>>>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>>>> do so by the toolstack.
>>>>>>
>>>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>>>> whatever bad they can do is by definition not a security concern.
>>>>>
>>>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>>>> it has already.  The main risk would be if there were bugs in the
>>>>> functionality that allowed security issues.
>>>>
>>>> Hmm, maybe I'm mis-reading the code, but
>>>> mem_access.c:set_mem_access() looks to be using the requested
>>>> access rights verbatim, i.e. without applying tool stack imposed
>>>> restrictions (hypervisor ones look to be honored by deriving
>>>> base permissions from the p2m type first).
>>>
>>> Quite likely I'm not grasping the full meaning of your objection,
>>> however the added code is merely another interface to already existing
>>> core code - so while admittedly there's room for improvement for the EPT
>>> code below it, this patch really only extends the scope of altp2m's
>>> existing version of set_mem_access() (which currently works on a single
>>> page). In that, it at least doesn't seem to make things worse (it's
>>> really just an optimization - whatever badness this code can cause with
>>> a single call, can already be achieved exactly with a sequence of
>>> xc_altp2m_set_mem_access() calls).
>>
>> I think Jan was saying that he would ideally like to remove *all* guest
>> access to altp2m functionality, even what's currently there.  The more
>> extra features we make available to guests, the harder it will be in the
>> future to argue to remove it all.
> 
> With one slight correction: all _uncontrolled_ access is what I'd like
> to see removed. Right now this could arguably indeed mean all
> access, as it is all uncontrolled (afaict).

Well at the moment all guest altp2m functionality is disabled unless the
toolstack has set the appropriate HVM param.  Is that not sufficient?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 15:54                     ` George Dunlap
@ 2017-12-11 15:58                       ` Razvan Cojocaru
  2017-12-11 16:24                       ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: Razvan Cojocaru @ 2017-12-11 15:58 UTC (permalink / raw)
  To: George Dunlap, Jan Beulich
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, George.Dunlap,
	Andrew Cooper, ian.jackson, xen-devel, Tamas K Lengyel

On 12/11/2017 05:54 PM, George Dunlap wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 15:51, <george.dunlap@citrix.com> wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>>>>> specifically is for an in-guest entity to have full control of all
>>>>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>>>>> do so by the toolstack.
>>>>>>>
>>>>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>>>>> whatever bad they can do is by definition not a security concern.
>>>>>>
>>>>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>>>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>>>>> it has already.  The main risk would be if there were bugs in the
>>>>>> functionality that allowed security issues.
>>>>>
>>>>> Hmm, maybe I'm mis-reading the code, but
>>>>> mem_access.c:set_mem_access() looks to be using the requested
>>>>> access rights verbatim, i.e. without applying tool stack imposed
>>>>> restrictions (hypervisor ones look to be honored by deriving
>>>>> base permissions from the p2m type first).
>>>>
>>>> Quite likely I'm not grasping the full meaning of your objection,
>>>> however the added code is merely another interface to already existing
>>>> core code - so while admittedly there's room for improvement for the EPT
>>>> code below it, this patch really only extends the scope of altp2m's
>>>> existing version of set_mem_access() (which currently works on a single
>>>> page). In that, it at least doesn't seem to make things worse (it's
>>>> really just an optimization - whatever badness this code can cause with
>>>> a single call, can already be achieved exactly with a sequence of
>>>> xc_altp2m_set_mem_access() calls).
>>>
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there.  The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to remove it all.
>>
>> With one slight correction: all _uncontrolled_ access is what I'd like
>> to see removed. Right now this could arguably indeed mean all
>> access, as it is all uncontrolled (afaict).
> 
> Well at the moment all guest altp2m functionality is disabled unless the
> toolstack has set the appropriate HVM param.  Is that not sufficient?

Furthermore, the parameters allow setting dom0-access only (courtesy of
Tamas' aforementioned patches).


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 15:05                   ` Jan Beulich
  2017-12-11 15:54                     ` George Dunlap
@ 2017-12-11 16:00                     ` Tamas K Lengyel
  2017-12-11 16:07                       ` Razvan Cojocaru
  1 sibling, 1 reply; 26+ messages in thread
From: Tamas K Lengyel @ 2017-12-11 16:00 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Petre Pircalabu, tim, Stefano Stabellini, wei.liu2,
	Razvan Cojocaru, George Dunlap, Andrew Cooper, Ian Jackson,
	George Dunlap, Xen-devel

On Mon, Dec 11, 2017 at 8:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 11.12.17 at 15:51, <george.dunlap@citrix.com> wrote:
>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>>>> specifically is for an in-guest entity to have full control of all
>>>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>>>> do so by the toolstack.
>>>>>>
>>>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>>>> whatever bad they can do is by definition not a security concern.
>>>>>
>>>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>>>> it has already.  The main risk would be if there were bugs in the
>>>>> functionality that allowed security issues.
>>>>
>>>> Hmm, maybe I'm mis-reading the code, but
>>>> mem_access.c:set_mem_access() looks to be using the requested
>>>> access rights verbatim, i.e. without applying tool stack imposed
>>>> restrictions (hypervisor ones look to be honored by deriving
>>>> base permissions from the p2m type first).
>>>
>>> Quite likely I'm not grasping the full meaning of your objection,
>>> however the added code is merely another interface to already existing
>>> core code - so while admittedly there's room for improvement for the EPT
>>> code below it, this patch really only extends the scope of altp2m's
>>> existing version of set_mem_access() (which currently works on a single
>>> page). In that, it at least doesn't seem to make things worse (it's
>>> really just an optimization - whatever badness this code can cause with
>>> a single call, can already be achieved exactly with a sequence of
>>> xc_altp2m_set_mem_access() calls).
>>
>> I think Jan was saying that he would ideally like to remove *all* guest
>> access to altp2m functionality, even what's currently there.  The more
>> extra features we make available to guests, the harder it will be in the
>> future to argue to remove it all.
>
> With one slight correction: all _uncontrolled_ access is what I'd like
> to see removed. Right now this could arguably indeed mean all
> access, as it is all uncontrolled (afaict).
>

But it is controlled. Unless you specifically allow the guest access
to the interface (ie altp2m=1 in the xl config) the guest can't do
anything with it. And if you do that, it is likely because you have an
in-guest agent that works in tandem with an out-of-guest agent
coordinating what to protect and how. You use the in-guest agent for
performance-sensitive monitoring while you can use the out-of-guest
agent to protect the in-guest agent. Of course, this is not a
requirement but what I *think* the setup was that the interface was
designed for as there is specific ability to decide which page
permission violation goes to the guest (with #VE) and which goes to
the toolstack. Plus even if the interface is enabled, it is only
available to the guest kernel. If it's a malicious guest kernel the
worst it should be able to do is crash itself (for example by
allocating a ton of altp2m tables and running out of shadow memory).
But I don't think you need the altp2m interface for a guest kernel to
crash itself.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 16:00                     ` Tamas K Lengyel
@ 2017-12-11 16:07                       ` Razvan Cojocaru
  0 siblings, 0 replies; 26+ messages in thread
From: Razvan Cojocaru @ 2017-12-11 16:07 UTC (permalink / raw)
  To: Tamas K Lengyel, Jan Beulich
  Cc: Petre Pircalabu, tim, Stefano Stabellini, wei.liu2,
	George Dunlap, Andrew Cooper, Ian Jackson, George Dunlap,
	Xen-devel

On 12/11/2017 06:00 PM, Tamas K Lengyel wrote:
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there.  The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to remove it all.
>>
>> With one slight correction: all _uncontrolled_ access is what I'd like
>> to see removed. Right now this could arguably indeed mean all
>> access, as it is all uncontrolled (afaict).
>>
> 
> But it is controlled. Unless you specifically allow the guest access
> to the interface (ie altp2m=1 in the xl config) the guest can't do
> anything with it. And if you do that, it is likely because you have an
> in-guest agent that works in tandem with an out-of-guest agent
> coordinating what to protect and how. You use the in-guest agent for
> performance-sensitive monitoring while you can use the out-of-guest
> agent to protect the in-guest agent. Of course, this is not a
> requirement but what I *think* the setup was that the interface was
> designed for as there is specific ability to decide which page
> permission violation goes to the guest (with #VE) and which goes to
> the toolstack. Plus even if the interface is enabled, it is only
> available to the guest kernel. If it's a malicious guest kernel the
> worst it should be able to do is crash itself (for example by
> allocating a ton of altp2m tables and running out of shadow memory).
> But I don't think you need the altp2m interface for a guest kernel to
> crash itself.

That's precisely how we envision possible use cases as well.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-10-24 10:19 [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages Petre Pircalabu
  2017-11-20  9:35 ` Petre Ovidiu PIRCALABU
  2017-12-08 12:18 ` Jan Beulich
@ 2017-12-11 16:18 ` George Dunlap
  2017-12-11 16:22 ` George Dunlap
  3 siblings, 0 replies; 26+ messages in thread
From: George Dunlap @ 2017-12-11 16:18 UTC (permalink / raw)
  To: Petre Pircalabu
  Cc: Tim Deegan, Stefano Stabellini, Wei Liu, Razvan Cojocaru,
	Andrew Cooper, Ian Jackson, xen-devel, Jan Beulich

On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu
<ppircalabu@bitdefender.com> wrote:
> From: Razvan Cojocaru <rcojocaru@bitdefender.com>
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2m subsystem, which could only set page restrictions for one
> page at a time. This patch addresses the gap.
>
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access rights - to alter these settings), in the absence of an
> official position on the issue from the original altp2m designers.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>

FWIW the approach looks good to me here.

You mainly need an x86 maintainer's ack and a toolstack maintainer's
ack (of which I am neither).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-10-24 10:19 [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages Petre Pircalabu
                   ` (2 preceding siblings ...)
  2017-12-11 16:18 ` George Dunlap
@ 2017-12-11 16:22 ` George Dunlap
  3 siblings, 0 replies; 26+ messages in thread
From: George Dunlap @ 2017-12-11 16:22 UTC (permalink / raw)
  To: Petre Pircalabu
  Cc: Tim Deegan, Stefano Stabellini, Wei Liu, Razvan Cojocaru,
	Andrew Cooper, Ian Jackson, xen-devel, Jan Beulich

On Tue, Oct 24, 2017 at 11:19 AM, Petre Pircalabu
<ppircalabu@bitdefender.com> wrote:
> From: Razvan Cojocaru <rcojocaru@bitdefender.com>
>
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2m subsystem, which could only set page restrictions for one
> page at a time. This patch addresses the gap.
>
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access rights - to alter these settings), in the absence of an
> official position on the issue from the original altp2m designers.
>
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com>

FWIW the approach looks good to me here.

You mainly need an x86 maintainer's ack and a toolstack maintainer's
ack (of which I am neither).

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages
  2017-12-11 15:54                     ` George Dunlap
  2017-12-11 15:58                       ` Razvan Cojocaru
@ 2017-12-11 16:24                       ` Jan Beulich
  1 sibling, 0 replies; 26+ messages in thread
From: Jan Beulich @ 2017-12-11 16:24 UTC (permalink / raw)
  To: George Dunlap
  Cc: Petre Pircalabu, tim, sstabellini, wei.liu2, Razvan Cojocaru,
	George.Dunlap, Andrew Cooper, ian.jackson, xen-devel,
	Tamas K Lengyel

>>> On 11.12.17 at 16:54, <george.dunlap@citrix.com> wrote:
> On 12/11/2017 03:05 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 15:51, <george.dunlap@citrix.com> wrote:
>>> On 12/11/2017 02:46 PM, Razvan Cojocaru wrote:
>>>> On 12/11/2017 03:36 PM, Jan Beulich wrote:
>>>>>>>> On 11.12.17 at 13:50, <george.dunlap@citrix.com> wrote:
>>>>>> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>>>>>>> On 11.12.17 at 12:06, <andrew.cooper3@citrix.com> wrote:
>>>>>>>> My suggestion was that we don't break usecases.  The Intel usecase
>>>>>>>> specifically is for an in-guest entity to have full control of all
>>>>>>>> altp2m functionality, and this is fine (security wise) when permitted to
>>>>>>>> do so by the toolstack.
>>>>>>>
>>>>>>> IOW you mean that such guests would be considered "trusted", i.e.
>>>>>>> whatever bad they can do is by definition not a security concern.
>>>>>>
>>>>>> I'm not sure what you mean by "trusted".  If implemented correctly,
>>>>>> altp2m and mem_access shouldn't give the guest any more permissions than
>>>>>> it has already.  The main risk would be if there were bugs in the
>>>>>> functionality that allowed security issues.
>>>>>
>>>>> Hmm, maybe I'm mis-reading the code, but
>>>>> mem_access.c:set_mem_access() looks to be using the requested
>>>>> access rights verbatim, i.e. without applying tool stack imposed
>>>>> restrictions (hypervisor ones look to be honored by deriving
>>>>> base permissions from the p2m type first).
>>>>
>>>> Quite likely I'm not grasping the full meaning of your objection,
>>>> however the added code is merely another interface to already existing
>>>> core code - so while admittedly there's room for improvement for the EPT
>>>> code below it, this patch really only extends the scope of altp2m's
>>>> existing version of set_mem_access() (which currently works on a single
>>>> page). In that, it at least doesn't seem to make things worse (it's
>>>> really just an optimization - whatever badness this code can cause with
>>>> a single call, can already be achieved exactly with a sequence of
>>>> xc_altp2m_set_mem_access() calls).
>>>
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there.  The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to remove it all.
>> 
>> With one slight correction: all _uncontrolled_ access is what I'd like
>> to see removed. Right now this could arguably indeed mean all
>> access, as it is all uncontrolled (afaict).
> 
> Well at the moment all guest altp2m functionality is disabled unless the
> toolstack has set the appropriate HVM param.  Is that not sufficient?

Together with someone enabling it rendering the system unsupported,
I can live with that (as said elsewhere). I'm probably just not going to
ack any patch similar to the one here (but I won't object to someone
else doing so).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2017-12-11 16:24 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-24 10:19 [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages Petre Pircalabu
2017-11-20  9:35 ` Petre Ovidiu PIRCALABU
2017-11-20 11:39   ` Jan Beulich
2017-12-08 12:18 ` Jan Beulich
2017-12-08 12:42   ` Razvan Cojocaru
2017-12-08 16:56     ` Tamas K Lengyel
2017-12-11  9:14     ` Jan Beulich
2017-12-11 11:06       ` Andrew Cooper
2017-12-11 12:12         ` Jan Beulich
2017-12-11 12:50           ` George Dunlap
2017-12-11 13:36             ` Jan Beulich
2017-12-11 14:46               ` Razvan Cojocaru
2017-12-11 14:51                 ` George Dunlap
2017-12-11 14:55                   ` George Dunlap
2017-12-11 15:05                   ` Jan Beulich
2017-12-11 15:54                     ` George Dunlap
2017-12-11 15:58                       ` Razvan Cojocaru
2017-12-11 16:24                       ` Jan Beulich
2017-12-11 16:00                     ` Tamas K Lengyel
2017-12-11 16:07                       ` Razvan Cojocaru
2017-12-11 15:03                 ` Jan Beulich
2017-12-11 14:50               ` George Dunlap
2017-12-11 14:58                 ` Jan Beulich
2017-12-11 15:38                   ` George Dunlap
2017-12-11 16:18 ` George Dunlap
2017-12-11 16:22 ` George Dunlap

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.