linux-kernel - Re: /sys/module/pcie_aspm/parameters/policy not writable?

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, 1 Aug 2013 13:33:20 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>
Cc:	Pavel Machek <pavel@....cz>, Greg KH <greg@...ah.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	Joe Lawrence <joe.lawrence@...atus.com>,
	Myron Stowe <myron.stowe@...hat.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"Rose, Gregory V" <gregory.v.rose@...el.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	"Duyck, Alexander H" <alexander.h.duyck@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Dave, Tushar N" <tushar.n.dave@...el.com>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: /sys/module/pcie_aspm/parameters/policy not writable?

On Thu, Aug 1, 2013 at 8:57 AM, Wyborny, Carolyn
<carolyn.wyborny@...el.com> wrote:
>> -----Original Message-----
>> From: Bjorn Helgaas [mailto:bhelgaas@...gle.com]
>> Sent: Wednesday, July 31, 2013 4:53 PM
>> To: Pavel Machek
>> Cc: Greg KH; kernel list; Joe Lawrence; Myron Stowe; Kirsher, Jeffrey T;
>> Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn; Skidmore, Donald C;
>> Rose, Gregory V; Waskiewicz Jr, Peter P; Duyck, Alexander H; Ronciak, John;
>> Dave, Tushar N; e1000-devel@...ts.sourceforge.net
>> Subject: Re: /sys/module/pcie_aspm/parameters/policy not writable?
>>
>> On Fri, Jul 19, 2013 at 11:46 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>>
>> > Just to make sure I understand you correctly: I think you are saying
>> > that the NIC has the same problem under Windows.
>>
>> Can you confirm or deny that the same problem occurs with Windows?
>
> In our testing here we saw the same problem with Windows.
>>
>> > But since the problem also occurs with Windows, it's pretty likely
>> > that there's a BIOS update to fix it.  I notice on the X60 support
>> > page that there are several versions newer than what you're running.
>>
>> Do you have any interest in trying a newer BIOS to see if it's fixed there?  If not, I
>> understand; BIOS updates are a hassle at best.
>> You're running BIOS 2.14, and it looks like the current BIOS for an
>> X60 1709 7HU is 2.19 (from http://support.lenovo.com).
>>
>> Carolyn's patch will likely work, at least most of the time, but I think there's a
>> small possibility that it could cause a conflict between the BIOS and the OS over
>> ASPM control, so I'm not 100% in support of that approach.  A conflict may not
>> happen on your machine, and not on my machine, but it may happen
>> somewhere, and if it does happen, it's likely to be rare and difficult to debug.
>>
> I've proposed a patch for Pavel to test.  I understand your position, but do you have any other proposal?  We have a severe hw problem we are trying alleviate as best we can.

I think the safest route is to change the BIOS so it either leaves
ASPM disabled, or enables it but grants control to the OS.  It seems
way too risky in general for the BIOS to enable ASPM and tell the OS
"you can't change this."  There's no way the BIOS can know about
device errata that may make ASPM unsafe.

If the same problem happens on Windows, I can hardly believe the BIOS
would pass Windows logo testing or that customers would tolerate it,
so I would think vendors would step up and update the BIOS.  This is a
built-in device, for goodness sake!  It's not like this is some random
plug-in device that the vendor might not have tested.

At a minimum, I think it would be good if the driver logged a warning
about "ASPM enabled and device may not work; check for BIOS update" so
future issues would be easier to debug.  For the reason above, I'm not
comfortable forcing the disable in the PCI core.  It *might* make
sense to forcibly disable ASPM in the driver if you're willing to take
the risk of conflicts, but I think you should also log a warning in
that case so you have a clue if a conflict does turn up somewhere.

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/