linux-kernel - Re: 2.6.32-rc4: Reported regressions from 2.6.31

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Oct 2009 21:29:19 +0100
From:	David Woodhouse <david.woodhouse@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>
Subject: Re: 2.6.32-rc4: Reported regressions from 2.6.31

On Mon, 2009-10-12 at 18:35 +0100, Linus Torvalds wrote:
> 
> On Mon, 12 Oct 2009, David Woodhouse wrote:
> > 
> > > The other solution would be to just _enable_ (and do all the setup) of the 
> > > IOMMU early. And then just leave a legacy mapping for the IOMMU, and then 
> > > _after_all_devices_are_set_up_ can you then remove the legacy mapping.
> > 
> > That involves allocating a _shitload_ of page tables for a 1:1 mapping
> > of all of physical memory.
> 
> I don't think that's true.
> 
> Nobody cares about "all physical memory". For one thing, we know that 
> anything that we consider to be normal memory (ie it's listed in the e820 
> tables as RAM) can't be all that interesting, since the BIOS definitely 
> released that to us.

Yeah, that's probably true. I was thinking of the 1:1 mappings we set up
for crappy drivers under Linux, which do need access to all of memory
and don't use the DMA API correctly. This is different, though.

We have talked about dma-mapping all of E820-reserved memory, but that
would allow a rogue device to scribble over arbitrary bits of memory
belonging to the BIOS, which isn't necessarily such a good thing. Even
if we did tear it down as soon as a real driver came along, the TXT
folks would still object -- and rightly so.

As you said, it's sufficient just to enable the IOMMU after the quirks
have run. So the patches I posted earlier should be just fine.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/