[PATCH] x86: constrain MFN range Dom0 may access

[PATCH] x86: constrain MFN range Dom0 may access

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

... to that covered by the physical address width supported by the
processor. This implicitly avoids Dom0 (accidentally or due to some
kind of abuse) passing out of range addresses to a guest, which in
turn eliminates this only possibility for PV guests to create PTEs
with one or more reserved bits set.

Note that this is not a security issue due to XSA-77.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -1533,7 +1533,7 @@ int __init construct_dom0(
 
     /* The hardware domain is initially permitted full I/O capabilities. */
     rc |= ioports_permit_access(d, 0, 0xFFFF);
-    rc |= iomem_permit_access(d, 0UL, ~0UL);
+    rc |= iomem_permit_access(d, 0UL, (1UL << (paddr_bits - PAGE_SHIFT)) - 1);
     rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
 
     /*
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4604,7 +4604,7 @@ struct memory_map_context
 static int _handle_iomem_range(unsigned long s, unsigned long e,
                                struct memory_map_context *ctxt)
 {
-    if ( s > ctxt->s )
+    if ( s > ctxt->s && !(s >> (paddr_bits - PAGE_SHIFT)) )
     {
         e820entry_t ent;
         XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;




[-- Attachment #2: x86-constrain-Dom0-MFN-range.patch --]
[-- Type: text/plain, Size: 1326 bytes --]

x86: constrain MFN range Dom0 may access

... to that covered by the physical address width supported by the
processor. This implicitly avoids Dom0 (accidentally or due to some
kind of abuse) passing out of range addresses to a guest, which in
turn eliminates this only possibility for PV guests to create PTEs
with one or more reserved bits set.

Note that this is not a security issue due to XSA-77.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -1533,7 +1533,7 @@ int __init construct_dom0(
 
     /* The hardware domain is initially permitted full I/O capabilities. */
     rc |= ioports_permit_access(d, 0, 0xFFFF);
-    rc |= iomem_permit_access(d, 0UL, ~0UL);
+    rc |= iomem_permit_access(d, 0UL, (1UL << (paddr_bits - PAGE_SHIFT)) - 1);
     rc |= irqs_permit_access(d, 1, nr_irqs_gsi - 1);
 
     /*
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4604,7 +4604,7 @@ struct memory_map_context
 static int _handle_iomem_range(unsigned long s, unsigned long e,
                                struct memory_map_context *ctxt)
 {
-    if ( s > ctxt->s )
+    if ( s > ctxt->s && !(s >> (paddr_bits - PAGE_SHIFT)) )
     {
         e820entry_t ent;
         XEN_GUEST_HANDLE_PARAM(e820entry_t) buffer_param;

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH] x86: constrain MFN range Dom0 may access

[Andrew Cooper]

On 20/01/16 15:38, Jan Beulich wrote:
> ... to that covered by the physical address width supported by the
> processor. This implicitly avoids Dom0 (accidentally or due to some
> kind of abuse) passing out of range addresses to a guest, which in
> turn eliminates this only possibility for PV guests to create PTEs
> with one or more reserved bits set.
>
> Note that this is not a security issue due to XSA-77.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>