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 10:35:06 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Woodhouse <david.woodhouse@...el.com>
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, 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.

That said, as long as the IOMMU is clearly enabled after the quirks have 
run, for this particular case we don't much care.

But I could also imagine something similar happening for some BIOS-enabled 
ethernet device being set up to listen to packets into some BIOS data 
areas (left-overs from whatever bootp thing or other), which doesn't have 
a quirk, and which ends up doing DMA until we actually load the driver.

Of course, we'd hope that the DMA just fails and nothing bad really 
happens (hopefully the driver re-init will clear up any hung device). But 
I can also imagine the hardware simply being really really unhappy, and 
not recovering.

So in many ways it would be safest to leave memory that we don't know 
about and we don't own as DMA'able in the IOMMU.

And no, I don't think it would be a shitload of pages. Quite the reverse. 
It's probably not very many at all.

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