WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges fr

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "xense-devel@xxxxxxxxxxxxxxxxxxx" <xense-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Tue, 20 Jan 2009 23:41:02 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Wang, Shane" <shane.wang@xxxxxxxxx>
Delivery-date: Tue, 20 Jan 2009 23:41:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C59B4275.217D4%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4F65016F6CB04E49BFFA15D4F7B798D92D629768@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C59B4275.217D4%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl6wsxj6VC8E6tgRhOE8Ctp6+7wEQAGlCg5ABXGpGA=
Thread-topic: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0

We had an earlier version of our patch that just altered the e820 table, but we were concerned about the code complexity needed to do that (the existing Xen e820 fns aren’t sufficient for this).  Here is the change that we would need to add—do you prefer this:

 

diff -r dbac9ee4d761 xen/arch/x86/e820.c

--- a/xen/arch/x86/e820.c     Mon Sep 08 16:02:13 2008 +0100

+++ b/xen/arch/x86/e820.c     Sat Nov 22 02:04:51 2008 +0800

@@ -373,11 +373,13 @@ static void __init machine_specific_memo

     reserve_dmi_region();

 }

 

-/* Reserve RAM area (@s,@e) in the specified e820 map. */

-int __init reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e)

+static int reserve_e820(uint32_t type, struct e820map *e820,

+                        uint64_t s, uint64_t e, uint32_t t)

 {

     uint64_t rs = 0, re = 0;

-    int i;

+    int i, remove;

+

+    remove = (type == t);

 

     for ( i = 0; i < e820->nr_map; i++ )

     {

@@ -388,55 +390,131 @@ int __init reserve_e820_ram(struct e820m

             break;

     }

 

-    if ( (i == e820->nr_map) || (e820->map[i].type != E820_RAM) )

+    if ( (i == e820->nr_map) || (e820->map[i].type != type) )

         return 0;

 

     if ( (s == rs) && (e == re) )

     {

         /* Complete excision. */

-        memmove(&e820->map[i], &e820->map[i+1],

-                (e820->nr_map-i-1) * sizeof(e820->map[0]));

-        e820->nr_map--;

+        if (remove)

+        {

+            memmove(&e820->map[i], &e820->map[i+1],

+                    (e820->nr_map-i-1) * sizeof(e820->map[0]));

+            e820->nr_map--;

+        }

+        else

+            e820->map[i].type = t;

     }

     else if ( s == rs )

     {

-        /* Truncate start. */

+        /* If not remove, split it in two, or else, truncate start. */

+        if (!remove)

+        {

+            if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )

+            {

+                printk("e820 overflow\n");

+                return 0;

+            }

+            memmove(&e820->map[i+1], &e820->map[i],

+                    (e820->nr_map-i) * sizeof(e820->map[0]));

+            e820->nr_map++;

+            e820->map[i].addr = s;

+            e820->map[i].size = e - s;

+            e820->map[i].type = t;

+            i++;

+        }

         e820->map[i].addr += e - s;

         e820->map[i].size -= e - s;

     }

     else if ( e == re )

     {

-        /* Truncate end. */

-        e820->map[i].size -= e - s;

-    }

-    else if ( e820->nr_map < ARRAY_SIZE(e820->map) )

-    {

-        /* Split in two. */

-        memmove(&e820->map[i+1], &e820->map[i],

-                (e820->nr_map-i) * sizeof(e820->map[0]));

-        e820->nr_map++;

-        e820->map[i].size = s - rs;

-        i++;

-        e820->map[i].addr = e;

-        e820->map[i].size = re - e;

+        /* If not remove, split it in two, or else, truncate end. */

+        if (!remove)

+        {

+            if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )

+            {

+                printk("e820 overflow\n");

+                return 0;

+            }

+            memmove(&e820->map[i+1], &e820->map[i],

+                    (e820->nr_map-i) * sizeof(e820->map[0]));

+            e820->nr_map++;

+            e820->map[i].size -= e - s;

+            i++;

+            e820->map[i].addr = s;

+            e820->map[i].size = e - s;

+            e820->map[i].type = t;

+        }

+        else

+            e820->map[i].size -= e - s;

     }

     else

     {

-        /* e820map is at maximum size. We have to leak some space. */

-        if ( (s - rs) > (re - e) )

+        /* If not remove, split in three, or else, split in two. */

+        if (!remove)

         {

-            printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n", e, re);

+            if ( e820->nr_map+2 > ARRAY_SIZE(e820->map) )

+            {

+                printk("e820 overflow\n");

+                return 0;

+            }

+            memmove(&e820->map[i+2], &e820->map[i],

+                    (e820->nr_map-i) * sizeof(e820->map[0]));

+            e820->nr_map += 2;

             e820->map[i].size = s - rs;

+            i++;

+            e820->map[i].addr = s;

+            e820->map[i].size = e - s;

+            e820->map[i].type = t;

+            i++;

+            e820->map[i].addr = e;

+            e820->map[i].size = re - e;

         }

         else

         {

-            printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n", rs, s);

-            e820->map[i].addr = e;

-            e820->map[i].size = re - e;

+            if ( e820->nr_map < ARRAY_SIZE(e820->map) )

+            {

+                memmove(&e820->map[i+1], &e820->map[i],

+                        (e820->nr_map-i) * sizeof(e820->map[0]));

+                e820->nr_map++;

+                e820->map[i].size = s - rs;

+                i++;

+                e820->map[i].addr = e;

+                e820->map[i].size = re - e;

+            }

+            else

+            {

+                /* e820map is at maximum size. We have to leak some space. */

+                if ( (s - rs) > (re - e) )

+                {

+                    printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n",

+                           e, re);

+                    e820->map[i].size = s - rs;

+                }

+                else

+                {

+                    printk("e820 overflow: leaking RAM %"PRIx64"-%"PRIx64"\n",

+                           rs, s);

+                    e820->map[i].addr = e;

+                    e820->map[i].size = re - e;

+                }

+            }

         }

     }

 

     return 1;

+}

+

+/* Reserve RAM area (@s,@e) in the specified e820 map. */

+int __init reserve_e820_ram(struct e820map *e820, uint64_t s, uint64_t e)

+{

+    return reserve_e820(E820_RAM, e820, s, e, E820_RAM);

+}

+

+/* Reserve RESERVE area (@s, @e) as UNUSABLE in the specified e820 map. */

+int reserve_e820_reserved(struct e820map *e820, uint64_t s, uint64_t e)

+{

+    return reserve_e820(E820_RESERVED, e820, s, e, E820_UNUSABLE);

 }

 

 unsigned long __init init_e820(

 

 

From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Tuesday, January 20, 2009 12:57 AM
To: Cihula, Joseph; xen-devel@xxxxxxxxxxxxxxxxxxx; xense-devel@xxxxxxxxxxxxxxxxxxx
Cc: Wang, Shane
Subject: Re: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from dom0

 

Xen tracks protected memory regions in its private e820 structure. If tboot is no longer marking E820_UNUSABLE in e820, then have Xen manually add the regions to its private e820. Then you won’t need your new ad hoc structure plus needing to process that new structure in various places.

 -- Keir

On 20/01/2009 05:49, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:

tboot no longer marks the TXT heap/SINIT/private config space as E820_UNUSABLE in the e820 table, so Xen must explicitly disallow those regions from dom0.

Signed-off-by: Shane Wang <shane.wang@xxxxxxxxx>
Signed-off-by: Joseph Cihula <joseph.cihula@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel