linux-kernel - Re: [PATCH 1/2] x86, ioapic: Reserve only 128 bytes for IOAPICs

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:	Thu, 25 Aug 2011 18:17:06 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ralf Jung <ralfjung-e@....de>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Yinghai Lu <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] x86, ioapic: Reserve only 128 bytes for IOAPICs

On Thu, Aug 25, 2011 at 5:33 PM, Suresh Siddha
<suresh.b.siddha@...el.com> wrote:
> On Thu, 2011-08-25 at 16:05 -0700, Bjorn Helgaas wrote:
>> Previously we reserved 1024 bytes, but that's more space than the IOAPIC
>> consumes, and it can cause conflicts with nearby devices.  The known
>> requirement is 68 bytes (sizeof(struct io_apic)), and rounding up to a
>> power-of-2 gives us 128.
>>
>
> Bjorn, Given the info from Intel that most of its io-apic
> implementations has registers up to 0xff offset (reserved), does
> reserving just the 128 bytes for the io-apic cause any address conflicts
> if the next 128 bytes are allocated (by the OS) for any other device.

If the OS allocated the next 128 bytes to another device, it sounds
like it would cause a conflict on Intel boxes.  This must be an area
that differs between vendors.  I haven't seen a spec that mentions 256
bytes as the required minimum MMIO size for IOAPICs, and apparently
the AMD IOAPIC decodes 240 bytes or fewer.

> Or OS doesn't allocate this range to any other device and its only the
> bios which allocates the addresses in this range and OS just ensures
> that there are no conflicts?

This patch only changes the region marked "busy" by the IOAPIC code.
This is analogous to a driver using request_mem_region() to show what
it's using.

That's different from the information about the range decoded by a
device, e.g,. what we learn from PCI BARs or ACPI _CRS.  We always
need this kind of information so we can avoid handing out that space
to another device, even if the driver isn't loaded or we aren't using
the IOAPICs, e.g., booting with "noapic".

This patch doesn't change the "range decoding" information, so I think
we're fairly safe.  I'm not sure we're completely safe because some
machines have PNP0C01 devices that cover the IOAPIC area, some have
E820 "reserved" areas, and some have both, and we currently ignore
PNP0C01 resources that conflict with E820 ones.

But I think we'd only see a problem if a machine had neither PNP0C01
nor E820 descriptions of that space (in that case, "noapic" is already
broken), if we had an E820 description that only covered *part* of an
IOAPIC (seems unlikely to me), or if we had no E820 but had a PNP0C01
that covered part of it.

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