linux-kernel - Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

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, 23 Jun 2016 00:47:49 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>,
	Mario Limonciello <Mario_Limonciello@...l.com>
Cc:	Rafael Wysocki <rafael@...nel.org>,
	Peter Jones <pjones@...hat.com>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] ACPI: don't show an error when we're not in charge of
 PCIe hotplug.

On Wed, Jun 22, 2016 at 10:53 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Wed, Jun 22, 2016 at 12:43 PM,  <Mario_Limonciello@...l.com> wrote:
>>> -----Original Message-----
>>> From: rjwysocki@...il.com [mailto:rjwysocki@...il.com] On Behalf Of

[cut]

>> I think changing that would help communicate what's going on here and at
>> least let the user know the result will be that the firmware is still controlling
>> ASPM due to the _OSC failure.

You seem to be assuming that all systems returning "unsupported UUID"
from the PCI host bridge _OSC will always fall into the same category,
but what if they don't?  What if at least some of them are really
broken?

>> Something else that I think Andy recommended a while back was at that
>> time try to evaluate NEXP and display its value and an associated message
>> in debug logs when _OSC fails.  Would you be amenable to a change like that?
>
> That seems dangerous if NEXP is anything other than a SystemMemory
> variable.  I don't know if there's a clean way to check that before
> evaluating it.  (i.e. we don't want to hit some other thing called
> NEXP that has side effects.)

Well, that's generic code and NEXP is not generic really, so agreed.

Thanks,
Rafael