[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Critical bug: VT-d fault causes disk corruption or Dom0 kernel panic.
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] > Sent: Saturday, January 24, 2009 1:27 AM > > On 24/01/2009 09:15, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote: > > >> 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? > > > > That's an orthogonal issue to avoiding Xen's RAM, but it at least ought to > > be easy to do. As long as it doesn't skip any private BIOS buffers for any > > devices which are still fully or partially under BIOS control (e.g., via > > SMM). But any such buffers above max_page would already be skipped. > > > > I can check in a patch for this as well as a patch to fix xen_in_range(). > > I'll do both. > > Changesets 19081 and 19082. Since the tboot memory is marked as reserved or unusable, the tboot_in_range() call is no longer needed. Do you want me to add that to my patch set? You've used a call to memory_is_conventional_ram() to check whether the page is in non-reserved RAM, but in looking at the function (below), I don't see how the '(e820.map[i].size > p)' test is valid--shouldn't it be '((e820.map[i].addr + e820.map[i].size) > p)'? int memory_is_conventional_ram(paddr_t p) { int i; for ( i = 0; i < e820.nr_map; i++ ) { if ( (e820.map[i].type == E820_RAM) && (e820.map[i].addr <= p) && (e820.map[i].size > p) ) return 1; } return 0; } _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |