linux-kernel - Re: [bug] mapping multiple BARs

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: <20160413194058.GA5569@localhost>
Date:	Wed, 13 Apr 2016 14:40:58 -0500
From:	Bjorn Helgaas <helgaas@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <ak@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"mingo@...e.hu" <mingo@...e.hu>, Borislav Petkov <bp@...e.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Zhang Rui <rui.zhang@...el.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [bug] mapping multiple BARs

Hi Jiri and Boris,

On Thu, Mar 24, 2016 at 10:44:41AM +0100, Jiri Olsa wrote:
> hi,
> I'm hitting following lines in dmesg:
>   resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than reserved [mem 0xfed10000-0xfed13fff]
>   caller snb_uncore_imc_init_box+0x7c/0xa0 mapping multiple BARs
> 
> I'm on IvyBridge model 58
>   vendor_id       : GenuineIntel
>   cpu family      : 6
>   model           : 58
>   model name      : Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
>   stepping        : 9
>   microcode       : 0x1c
> 
> I've read following threads:
>   http://marc.info/?w=2&r=1&s=mapping+multiple+BARs&q=t
> 
> and it seems this is supposed to be already fixed by:
>   cb171f7abb9a PNP: Work around BIOS defects in Intel MCH area reporting

The case fixed by cb171f7abb9a was this (taken from a dmesg from Dave
Jones at http://marc.info/?l=linux-kernel&m=139769397501891&w=2):

  BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
  pci 0000:00:00.0: [8086:0154] type 00 class 0x060000
  system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
  resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01   

In that case, the resource tree looked like this:

  fed10000-fed19fff : reserved
    fed10000-fed13fff : system 00:01

The E820 map reservation is fine, but the system 00:01 reservation is
too small.  We complain because snb_uncore_imc_init_box() wanted to
reserve [mem 0xfed10000-0xfed15fff], which extended past the end of
the 00:01 reservation.

Here we have the same IvyBridge device but a slightly different problem:

> BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
> pci 0000:00:00.0: [8086:0154] type 00 class 0x060000
> system 00:07: [mem 0xfed10000-0xfed17fff] could not be reserved
> resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than reserved [mem 0xfed10000-0xfed13fff]
> caller snb_uncore_imc_init_box+0x7c/0xa0 mapping multiple BARs

In this case, the resource tree looks like this:

  fed10000-fed13fff : reserved

The E820 map reservation is too small, but it happens first and
succeeds.  The system 00:07 reservation is larger but fails because it
extends past the end of the E820 reservation.  And the
snb_uncore_imc_init_box() reservation failed similarly.

This is another case where we are getting burned by assuming
hierarchical relationships that do not necessarily exist between
E820 and ACPI resources.  If we could just take the union of those
reservations, and say "anything reserved by E820 *or* ACPI devices is
in use", these problems wouldn't occur.  But the resource tree
enforces these hierarchical relationships that are not required by
specs and often not actually present in the information from BIOS.

Bjorn