linux-kernel - Re: Avoid creating P2P prefetch window for expansion ROMs

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:	Tue, 27 Nov 2007 09:28:25 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Gary Hade" <garyhade@...ibm.com>
Cc:	<gregkh@...e.de>, <lcm@...ibm.com>, <linux-kernel@...r.kernel.org>
Subject: Re: Avoid creating P2P prefetch window for expansion ROMs

>A kernel without the patch always forced creation of a prefetch
>window for expansion ROMs which was incorrect on systems where
>insufficient memory resources are available for both non-prefetch
>and prefetch windows.  On the systems I was dealing with, the
>BIOS assumes (correctly, I believe) that expansion ROM memory
>resource needs will be satisfied from the non-prefetch window.

Why would ROM space generally need to be non-prefetchable? I can
see that special cases might require this, but as long as ROM space
really is just normal code and data, there's nothing wrong with
prefetching from it I would think. Of course I realize there's no way
to specify that on a per-device basis, so I think the BIOS must be
relied upon here.

>I think it would still be useful to know what system/PCI adapter
>combination you are seeing the problem with so that I can try
>to put together a setup that will reproduce the problem here.
>Alternatively, it would good if you wouldn't mind providing
>more information, testing possible fixes, etc.  As a start,
>could you send me the following taken with and without the
>patch?
>  - /proc/iomem
>  - /proc/ioports
>  - `dmesg` output
>  - `lspci -vt` output
>  - `lspci -vvv` output

Attached. *.0 is with the patch, *.1 is with it reverted. All output from
the SLE10SP2 (2.6.16.54-based) kernel that has that patch backported.

I'd also like to note that I found that a second of the systems I'm
regularly dealing with also has similar problems. I'm just not normally
looking at the boot messages that closely.

Jan


Download attachment "lspci-vvv.1" of type "application/octet-stream" (44808 bytes)

Download attachment "dmesg.1" of type "application/octet-stream" (35319 bytes)

Download attachment "iomem.0" of type "application/octet-stream" (1934 bytes)

Download attachment "iomem.1" of type "application/octet-stream" (2140 bytes)

Download attachment "ioports.0" of type "application/octet-stream" (951 bytes)

Download attachment "ioports.1" of type "application/octet-stream" (951 bytes)

Download attachment "lspci-vt.0" of type "application/octet-stream" (5106 bytes)

Download attachment "lspci-vt.1" of type "application/octet-stream" (5106 bytes)

Download attachment "lspci-vvv.0" of type "application/octet-stream" (44790 bytes)

Download attachment "dmesg.0" of type "application/octet-stream" (35433 bytes)