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

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

To: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Li, Haicheng" <haicheng.li@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Fri, 23 Jan 2009 16:34:44 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Fri, 23 Jan 2009 16:35:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <57C9024A16AD2D4C97DC78E552063EA35EED2BFD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <C59FBFF6.21CC8%keir.fraser@xxxxxxxxxxxxx> <C59FC075.21CCD%keir.fraser@xxxxxxxxxxxxx> <57C9024A16AD2D4C97DC78E552063EA35EED2BFD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl8Q3YVs3niaMuxT1CPWgfSc0ZGCwAITqg5AAKyJXAAAOMrHgAfiHegABEJqTgAEqyPIAACkS3lAAAS7KQACh68wAAB9ZoQ
Thread-topic: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
> From: Kay, Allen M
> Sent: Friday, January 23, 2009 3:40 PM
>
> 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

But excluding the Xen text sections using is_kernel_text().

Joe

>
> -----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

<Prev in Thread] Current Thread [Next in Thread>