RE: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

I talked to Joe Cihula about this.  He is suggesting map only the RAM memory in 
E820 table.  This is more secure than map everything below max_page.  We can do 
this for x86_64 and x86_32.  For IA-64, we still map everything below max_page 
as there is no tboot issue.

What do you think of is approach?

Allen

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: Friday, January 23, 2009 10:44 AM
To: Kay, Allen M; Li, Xin; Li, Haicheng; 'xen-devel@xxxxxxxxxxxxxxxxxxx'
Subject: Re: [Xen-devel] Critical bug: VT-d fault causes disk corruption or 
Dom0 kernel panic.

On 23/01/2009 18:41, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> Also it's going to be hard to do better while keeping efficiency since if you
> only map dom0's pages in its vtd tables then PV backend drivers will not work
> (which rely on DMAing to/from other domain's pages via grant references).
> You'd have to dynamically map/unmap as grants get mapped/unmapped, and you may
> not want the performance hit of that.
>
> I'd personally vote for getting rid of xen_in_range(). Alternatively we could
> have it merely check for is_kernel_text(), but really I think since it is not
> in any way full protection from dom0 I wonder if it is worth the bother at
> all.
>
> What do you think?

I should add that you could still implement the more sophisticated and
slower full protection, where dom0 only has DMA access to pages it currently
has access to via the host CPUs, as a boot option. For those who really
don't want to trust dom0 as far as possible.

 -- Keir



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

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