linux-kernel - Re: [PATCH 1/2 v6] x86/kexec_file: add e820 entry in case e820 type string matches to io resource name

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] [day] [month] [year] [list]

Message-ID: <20181121184232.GB27559@zn.tnic>
Date:   Wed, 21 Nov 2018 19:42:32 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     bjorn@...gaas.com
Cc:     lijiang@...hat.com, Bjorn Helgaas <helgaas@...nel.org>,
        linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        x86 <x86@...nel.org>, tglx@...utronix.de,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>, dyoung@...hat.com,
        bhe@...hat.com
Subject: Re: [PATCH 1/2 v6] x86/kexec_file: add e820 entry in case e820 type
 string matches to io resource name

On Tue, Nov 20, 2018 at 02:43:57PM -0600, Bjorn Helgaas wrote:
> MMCONFIG (aka ECAM) space is described in the ACPI MCFG table.  The
> generic code to read that is in drivers/acpi/pci_mcfg.c (ignore all
> the quirks at the top) and the generic code to use it is
> drivers/pci/ecam.c.

/me saves that for future reference.

> Unfortunately x86 doesn't use any of that generic path.  It uses the
> same MCFG table, but it's parsed in arch/x86/pci/mmconfig-shared.c,
> and the code there checks to ensure the ECAM regions are reserved
> somehow by firmware, e.g., via the e820 table.

As they are on my workstation here, for example:

[    0.552607] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820

vs the "ACPI motherboard resources" reservation thing where it traverses
some PNP devices.

> There's a bunch of grungy device-dependent code there, too, possibly
> to work around firmware defects, or (just as likely) to compensate for
> Linux defects that were *attributed* to firmware.

Nah, latter we simply fix. :-)

> I think you should regard correct MCFG/ECAM usage in the kdump kernel
> as a requirement.  If you don't have ECAM (a) PCI devices won't work
> at all on non-x86 systems that use only ECAM for config access, (b)
> you won't be able to access devices on non-0 segments (granted, there
> aren't very many of these yet, but there will be more in the future),

Ah. don't worry, someone will pop up from the woodwork with the need for
this ;-\

> and (c) you won't be able to access extended config space (addresses
> 0x100-0xfff), which means none of the Extended Capabilities will be
> available (AER, ACS, ATS, etc).

Yap, and this answers my question:

e820__mapped_all() is being called with E820_TYPE_RESERVED down the path
in pci_mmcfg_check_reserved(). Which basically says that we need to
provide all reserved regions in the second kernel so that MMCONFIG works
there.

Thanks a lot Bjorn!

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.