linux-kernel - Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU

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:	Wed, 6 Jun 2012 10:16:00 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Don Dutile <ddutile@...hat.com>, iommu@...ts.linux-foundation.org,
	mingo@...e.hu, linux-kernel@...r.kernel.org, chrisw@...hat.com,
	suresh.b.siddha@...el.com
Subject: Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU


* David Woodhouse <dwmw2@...radead.org> wrote:

> > well, one could argue it may be easier to claim the space 
> > reserved in the OS then making yet another hole in the 
> > available IO address space in the ACPI tables.
> 
> But how? It's got to work with operating systems that predate 
> the IOMMU. The registers *have* to be in a marked hole. If 
> *not*, then we should give a clear "YOUR BIOS IS BROKEN" 
> output like all the similar breakages, and do our best to work 
> around it.
> 
> Working around it is fine; I'm not suggesting that we should 
> WARN() *instead* of working around it.

So basically the patch-set is fine as-is, we just want a 
sufficiently nasty sounding warning message about the BIOS bug, 
with actionable output, something like:

     ... the kernel is sad because a buggy BIOS has not 
         marked IOMMU area xxx-yyy as reserved, working
         it around. You get to keep all the pieces and
         be more careful with remaining eye.

(or a functional equivalent thereof.)

this patch could be added as a third patch in the series, right?

> >   The BIOS's are getting better, but I've seen turtles run 
> >   faster... ;-) .
> 
> Thankfully, there are now some modern Intel systems on which 
> you can run Coreboot. This should be a huge benefit — you 
> should be able to build an up-to-date Tianocore and deploy it 
> as your Coreboot payload, rather than having to put up with 
> the crap that's on the system when you receive it.

If we could integrate Coreboot into the kernel and could build a 
bzImage that one could write into the BIOS flash image and thus 
have an updated and functional BIOS, that would be awesome.

People could actually write systems with proper 'every pixel is 
perfect' boot output and low latency behavior from the moment 
power is turned on to the first desktop GUI frame and such.

(With some fail safe mechanism for bugs.)

And ponies.

Thanks,

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