linux-kernel - Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic Toughbook S10

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: <20120706180635.GB17196@google.com>
Date:	Fri, 6 Jul 2012 12:06:35 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jiang Liu <liuj97@...il.com>
Cc:	Bill Unruh <unruh@...sics.ubc.ca>, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org
Subject: Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic
 Toughbook S10

On Sat, Jun 02, 2012 at 11:30:23AM +0800, Jiang Liu wrote:
> ... address range 0xfed98000-0xfed9ffff has been reserved by motherboard
> device(PNP0C02).  I guess that BIOS has assigned address "0xfed98000" to
> 0000:00:04.0 for thermal management functionality. The BAR0 of
> 0000:00:04.0 may be locked down (can't be changed by OS) because the ACPI
> BIOS may have dependency on the assigned address ranges.

I don't think the BAR can be completely read-only.  If it were, we wouldn't
have any way to determine its size.  We believe it is 32K in size:

    pci 0000:00:04.0: reg 10: [mem 0xfed98000-0xfed9ffff 64bit]

so we should have written 0xffffffff to the low 32 bits of the BAR and read
back 0xffff8004 (32K = 2^15, so the low-order 15 bits should be read-only,
including the prefetchable bit (0), the type bits (10 for 64-bit), and the
memory space indicator (0)).

Can you experiment with setting that BAR manually, e.g., by running these
commands as root:

    # setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1
    # setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa00000
    # setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1

That's basically what the kernel does in pci_update_resource(), so this
will likely fail, too.

In __pci_read_base(), where we size the BAR, we disable decoding first,
which we *don't* do in pci_update_resource().  So if the above doesn't
work, can you try this:

    # setpci -s 00:04.0 COMMAND BASE_ADDRESS_0 BASE_ADDRESS_1
    # setpci -s 00:04.0 COMMAND=0
    # setpci -s 00:04.0 BASE_ADDRESS_0=0xdfa00000
    # setpci -s 00:04.0 BASE_ADDRESS_0 BASE_ADDRESS_1

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