thr3ads.net - Xen devel - [Xense-devel] [PATCH] txt: 1/6 - "fix" xen_phys

If this information is useful, please help other people find it:
Share via:

Cihula, Joseph

2009-Jan-20 05:48 UTC

[Xense-devel] [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

On IA32 (32b/32b PAE) builds, set xen_phys_start (and by extension
xenheap_phys_start) to be the start of hypervisor code (instead of 0).  This
reflects the actual trust/protection boundary of the hypervisor.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>

diff -r 8df3c145923f -r f96073a97f5c xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c      Mon Jan 19 17:40:28 2009 +0000
+++ b/xen/arch/x86/setup.c      Mon Jan 19 20:22:24 2009 -0800
@@ -843,7 +843,7 @@ void __init __start_xen(unsigned long mb
     /* Initialise the Xen heap. */
     init_xenheap_pages(xenheap_phys_start, xenheap_phys_end);
     nr_pages = (xenheap_phys_end - xenheap_phys_start) >> PAGE_SHIFT;
-    xenheap_phys_start = xen_phys_start;
+    xenheap_phys_start = xen_phys_start = __pa(&_start);
     printk("Xen heap: %luMB (%lukB)\n",
            nr_pages >> (20 - PAGE_SHIFT),
            nr_pages << (PAGE_SHIFT - 10));

_______________________________________________
Xense-devel mailing list
Xense-devel@lists.xensource.com
http://lists.xensource.com/xense-devel

Keir Fraser

2009-Jan-20 08:59 UTC

head link

[Xen-devel] Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

Xen_phys/xenheap_phys has changed a bit since removing Xen heap for x86/64.
It sounds like you¹ll be re-sending these patches later once fixed up for
xen-unstable tip. Perhaps this won¹t be needed any more. I¹m not sure what
you¹re using xen_phys_start for, but it does sound dubious.

 -- Keir

On 20/01/2009 05:48, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:
> On IA32 (32b/32b PAE) builds, set xen_phys_start (and by extension
> xenheap_phys_start) to be the start of hypervisor code (instead of 0). 
This
> reflects the actual trust/protection boundary of the hypervisor.
> 
> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
> 
> diff -r 8df3c145923f -r f96073a97f5c xen/arch/x86/setup.c
> --- a/xen/arch/x86/setup.c      Mon Jan 19 17:40:28 2009 +0000
> +++ b/xen/arch/x86/setup.c      Mon Jan 19 20:22:24 2009 -0800
> @@ -843,7 +843,7 @@ void __init __start_xen(unsigned long mb
>      /* Initialise the Xen heap. */
>      init_xenheap_pages(xenheap_phys_start, xenheap_phys_end);
>      nr_pages = (xenheap_phys_end - xenheap_phys_start) >>
PAGE_SHIFT;
> -    xenheap_phys_start = xen_phys_start;
> +    xenheap_phys_start = xen_phys_start = __pa(&_start);
>      printk("Xen heap: %luMB (%lukB)\n",
>             nr_pages >> (20 - PAGE_SHIFT),
>             nr_pages << (PAGE_SHIFT - 10));
> 


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

Wang, Shane

2009-Jan-20 09:04 UTC

head link

[Xen-devel] RE: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

We are using xen_phys_start ~ xenheap_phys_end to check its integrity (for the
purpose of memory integrity protection) before and after Sx by MACing this
range.
It looks like xen heap is not continuous any more.

Shane
________________________________

From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] 
Sent: 2009年1月20日 17:00
To: Cihula, Joseph; xen-devel@lists.xensource.com;
xense-devel@lists.xensource.com
Cc: Wang, Shane
Subject: Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds


Xen_phys/xenheap_phys has changed a bit since removing Xen heap for x86/64. It
sounds like you’ll be re-sending these patches later once fixed up for
xen-unstable tip. Perhaps this won’t be needed any more. I’m not sure what
you’re using xen_phys_start for, but it does sound dubious.

 -- Keir

On 20/01/2009 05:48, "Cihula, Joseph" <joseph.cihula@intel.com>
wrote:



	On IA32 (32b/32b PAE) builds, set xen_phys_start (and by extension
xenheap_phys_start) to be the start of hypervisor code (instead of 0).  This
reflects the actual trust/protection boundary of the hypervisor.
	
	Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
	
	diff -r 8df3c145923f -r f96073a97f5c xen/arch/x86/setup.c
	--- a/xen/arch/x86/setup.c      Mon Jan 19 17:40:28 2009 +0000
	+++ b/xen/arch/x86/setup.c      Mon Jan 19 20:22:24 2009 -0800
	@@ -843,7 +843,7 @@ void __init __start_xen(unsigned long mb
	     /* Initialise the Xen heap. */
	     init_xenheap_pages(xenheap_phys_start, xenheap_phys_end);
	     nr_pages = (xenheap_phys_end - xenheap_phys_start) >> PAGE_SHIFT;
	-    xenheap_phys_start = xen_phys_start;
	+    xenheap_phys_start = xen_phys_start = __pa(&_start);
	     printk("Xen heap: %luMB (%lukB)\n",
	            nr_pages >> (20 - PAGE_SHIFT),
	            nr_pages << (PAGE_SHIFT - 10));
	
	


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

Keir Fraser

2009-Jan-20 09:09 UTC

head link

[Xen-devel] Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

Yeah, I would point out in any case that Xen has always allocated plenty of
''domheap'' memory and depends on the consistency of that too
(e.g., VT-d
tables, shadow page tables) so checking only Xen + Xen heap is insufficient
anyway.

Could you not just check all of memory, minus a few bits you expect can
change? I don''t think any other approach will be robust.

 -- Keir

On 20/01/2009 09:04, "Wang, Shane" <shane.wang@intel.com> wrote:
> We are using xen_phys_start ~ xenheap_phys_end to check its integrity (for
the
> purpose of memory integrity protection) before and after Sx by MACing this
> range.
> It looks like xen heap is not continuous any more.
> 
> Shane
> ________________________________
> 
> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
> Sent: 2009年1月20日 17:00
> To: Cihula, Joseph; xen-devel@lists.xensource.com;
> xense-devel@lists.xensource.com
> Cc: Wang, Shane
> Subject: Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b
builds
> 
> 
> Xen_phys/xenheap_phys has changed a bit since removing Xen heap for x86/64.
It
> sounds like you’ll be re-sending these patches later once fixed up for
> xen-unstable tip. Perhaps this won’t be needed any more. I’m not sure what
> you’re using xen_phys_start for, but it does sound dubious.
> 
>  -- Keir
> 
> On 20/01/2009 05:48, "Cihula, Joseph"
<joseph.cihula@intel.com> wrote:
> 
> 
> 
> On IA32 (32b/32b PAE) builds, set xen_phys_start (and by extension
> xenheap_phys_start) to be the start of hypervisor code (instead of 0). 
This
> reflects the actual trust/protection boundary of the hypervisor.
> 
> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
> 
> diff -r 8df3c145923f -r f96073a97f5c xen/arch/x86/setup.c
> --- a/xen/arch/x86/setup.c      Mon Jan 19 17:40:28 2009 +0000
> +++ b/xen/arch/x86/setup.c      Mon Jan 19 20:22:24 2009 -0800
> @@ -843,7 +843,7 @@ void __init __start_xen(unsigned long mb
>     /* Initialise the Xen heap. */
>     init_xenheap_pages(xenheap_phys_start, xenheap_phys_end);
>     nr_pages = (xenheap_phys_end - xenheap_phys_start) >> PAGE_SHIFT;
> -    xenheap_phys_start = xen_phys_start;
> +    xenheap_phys_start = xen_phys_start = __pa(&_start);
>     printk("Xen heap: %luMB (%lukB)\n",
>            nr_pages >> (20 - PAGE_SHIFT),
>            nr_pages << (PAGE_SHIFT - 10));
> 
> 
> 


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

Wang, Shane

2009-Jan-20 09:16 UTC

head link

[Xen-devel] RE: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

Yes, we have patch to check domains as well, but this kind of verification is
configurable, considering we don't want to spend much time on S3 and resume.
That will make S3 slow.

In our approach, we check domains in Xen and check Xen (Xen + Xen heap) in
tboot. We can't check Xen in Xen, since the memory is changing.

I think we need to figure out another approach, if Xen heap needs to be checked.

Shane

Keir Fraser wrote:> Yeah, I would point out in any case that Xen has always allocated
> plenty of 'domheap' memory and depends on the consistency of that
too
> (e.g., VT-d tables, shadow page tables) so checking only Xen + Xen
> heap is insufficient anyway.
> 
> Could you not just check all of memory, minus a few bits you expect
> can change? I don't think any other approach will be robust.
> 
>  -- Keir
> 
> On 20/01/2009 09:04, "Wang, Shane" <shane.wang@intel.com>
wrote:
> 
>> We are using xen_phys_start ~ xenheap_phys_end to check its
>> integrity (for the purpose of memory integrity protection) before
>> and after Sx by MACing this range. It looks like xen heap is not
>> continuous any more. 
>> 
>> Shane
>> ________________________________
>> 
>> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com]
>> Sent: 2009年1月20日 17:00
>> To: Cihula, Joseph; xen-devel@lists.xensource.com;
>> xense-devel@lists.xensource.com
>> Cc: Wang, Shane
>> Subject: Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b
builds
>> 
>> 
>> Xen_phys/xenheap_phys has changed a bit since removing Xen heap for
>> x86/64. It sounds like you’ll be re-sending these patches later once
>> fixed up for xen-unstable tip. Perhaps this won’t be needed any
>> more. I’m not sure what you’re using xen_phys_start for, but it does
>> sound dubious. 
>> 
>>  -- Keir
>> 
>> On 20/01/2009 05:48, "Cihula, Joseph"
<joseph.cihula@intel.com>
>> wrote: 
>> 
>> 
>> 
>> On IA32 (32b/32b PAE) builds, set xen_phys_start (and by extension
>> xenheap_phys_start) to be the start of hypervisor code (instead of
>> 0).  This reflects the actual trust/protection boundary of the
>> hypervisor. 
>> 
>> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
>> 
>> diff -r 8df3c145923f -r f96073a97f5c xen/arch/x86/setup.c
>> --- a/xen/arch/x86/setup.c      Mon Jan 19 17:40:28 2009 +0000
>> +++ b/xen/arch/x86/setup.c      Mon Jan 19 20:22:24 2009 -0800
>> @@ -843,7 +843,7 @@ void __init __start_xen(unsigned long mb
>>     /* Initialise the Xen heap. */
>>     init_xenheap_pages(xenheap_phys_start, xenheap_phys_end);
>>     nr_pages = (xenheap_phys_end - xenheap_phys_start) >>
PAGE_SHIFT;
>> -    xenheap_phys_start = xen_phys_start;
>> +    xenheap_phys_start = xen_phys_start = __pa(&_start);
>>     printk("Xen heap: %luMB (%lukB)\n",
>>            nr_pages >> (20 - PAGE_SHIFT),
>>            nr_pages << (PAGE_SHIFT - 10));

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

Keir Fraser

2009-Jan-20 09:24 UTC

head link

[Xen-devel] Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

On 20/01/2009 09:16, "Wang, Shane" <shane.wang@intel.com> wrote:
> Yes, we have patch to check domains as well, but this kind of verification
is
> configurable, considering we don''t want to spend much time on S3
and resume.
> That will make S3 slow.
> 
> In our approach, we check domains in Xen and check Xen (Xen + Xen heap) in
> tboot. We can''t check Xen in Xen, since the memory is changing.
> 
> I think we need to figure out another approach, if Xen heap needs to be
> checked.
The Xen page_info structure array which tells you about per-page usages is
itself not allocated out of Xen heap. :-)

What is your threat model for badness across S3? Untrusted BIOS, so you keep
your Xen measurement stashed in the TPM somehow?

 -- Keir



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

Xen devel - Jan 2009 - [Xense-devel] [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

[Xense-devel] [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

[Xen-devel] Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

[Xen-devel] RE: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

[Xen-devel] Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

[Xen-devel] RE: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds

[Xen-devel] Re: [PATCH] txt: 1/6 - "fix" xen_phys_start for 32b builds