linux-kernel - Re: [PATCH] x86-64: disable the GART before allocate aperture

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:	Fri, 22 Jun 2007 14:45:39 -0700
From:	Muli Ben-Yehuda <muli@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Yinghai Lu <Yinghai.Lu@....COM>, Andi Kleen <ak@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vivek Goyal <vgoyal@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86-64: disable the GART before allocate aperture

On Fri, Jun 22, 2007 at 03:32:53PM -0600, Eric W. Biederman wrote:
> Alan Cox <alan@...rguk.ukuu.org.uk> writes:
> 
> > You've got mapped live gart pages from the previous kernel. Even
> > if you disable the gart before a memset you may well have the
> > video card using gart translations and possibly live IOMMU
> > mappings for devices using it via bus mastering - and those will
> > cause you MCE exceptions with a corrupt cpu context flag (ie not
> > nicely recoverable).
> 
> The original plan (which we have not followed up on).  Was to
> reserve a chunk of any iommu for the kexec on panic kernel.  Then to
> just have the second kernel use that unused chunk.  This is how we
> treat the normal memory space and it seems a nice and simple
> approach to this kind of problem.
> 
> For a normal kexec we should shut everything down before the kernel
> transition so it should not be an issue.
> 
> YH do you think you can look at simply reserving a portion of the
> iommu?  And having the kexec on panic kernel use the reserved
> portion?

How would this work with an isolation capable IOMMU which has
different address spaces for different devices? (e.g., Calgary which
is in mainline, Intel's VT-d which is coming soon, etc).

Cheers,
Muli
-
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/