linux-kernel - Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

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]

Message-ID: <20171128215833.hhcjvn5qjfc3bdrk@dwarf.suse.cz>
Date:   Tue, 28 Nov 2017 22:58:33 +0100
From:   Jiri Bohac <jbohac@...e.cz>
To:     Baoquan He <bhe@...hat.com>
Cc:     yinghai@...nel.org, joro@...tes.org,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Toshi Kani <toshi.kani@....com>,
        David Airlie <airlied@...ux.ie>, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dave Young <dyoung@...hat.com>, Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

Hi Baoquan,

On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> Solution:
> 1) Remove the code which support GART IOMMU when it's not enabled in
> BIOS. This has been done in the new generation of hardware IOMMU like
> intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be
> exceptional.

Wouldn't this break old machines with actual AGP and
misconfigured/bugg BIOSes? Wasn't that the reason why we have the
workaround of mapping the hole over real memory?

> 2) Remove those pages from mm subsystem since they are not seen any more
> though they have been added into mm subsystem, because CPU can't see
> them.

not exactly sure I understand this... they are reserved by the
memblock allocater, thus preventing any further use by any mm
code.

> 3) Remove the apreture region from /proc/iomem so that pages in that
> region can't be seen by kdump kernel. This is easier, but just a work
> around.

I like this idea, but won't this cause pci_claim_resource() fail
after the call to pci_find_parent_resource() ? See my previous
mail.

Bad thing is, we don't want to break random old AGP hardware, but
at the same time, it's now too rare to properly test this.

So wouldn't it be better to fix the problem at least for the
kexec_file case using my original patch?

A possible hack for the old kexec syscall might be to
make /proc/iomem list the "GART" region without it being present in
the iomem resource database. kexec-tools has working code to deal with
the GART region, but the kernel no longer includes it in
/proc/iomem.

Or maybe a cleaner solution than special-casing the "GART" region
into /proc/iomem would be to introduce a new type of iomem
resource that would be visible in /proc/iomem but would allow
other resources to be requested even when overlapping the region of this
special resource? This way, we could insert the "GART" resource
when allocating the hole but later, when an actual AGP driver
requests the range during PCI enumeration, the "GART" resource
would be overwrtiten by the actual PCI resource.

-- 
Jiri Bohac <jbohac@...e.cz>
SUSE Labs, Prague, Czechia