linux-kernel - Re: [Patch] acpi_power_meter: remove 'ignoring unsafe software power cap' message

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: <20180907233201.GA4635@magnolia>
Date:   Fri, 7 Sep 2018 16:32:02 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Max Asbock <masbock@...ovo.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Chris McDermott <lcm@...ovo.com>
Subject: Re: [Patch] acpi_power_meter: remove 'ignoring unsafe software power
 cap' message

On Fri, Sep 07, 2018 at 10:07:39PM +0000, Max Asbock wrote:
> At boot time the acpi_power_meter driver greets users of non-IBM systems with the message: 
> 	
> "Ignoring unsafe software power cap". 
> 
> This message is generally interpreted as meaning: The system is
> operating under an unsafe power  cap and Linux is ignoring this fact,
> thus living dangerously. It, or its presumed origin, has been blamed
> for system crashes. People spent time writing knowledge base articles
> which explain that the message doesn't mean what users think. I now
> have to write another such article telling people to ignore this
> message. To avoid future confusion and unnecessary work, I think the
> best solution is to remove the message. 
> 
> Here is my translation of the 'ignoring unsafe power cap' message:
>
> 'The acpi_power_meter driver discovered an ACPI object that would in
> theory allow software to set power caps. The driver could now create
> files in sysfs to expose this interface to user space, but it chooses
> not to do so'.

TBH that driver safelists the (single) system that is known to have a
working power capping mechanism.  At the time (ten years ago) the AEM
group worried that other vendors would produce ACPI power meters which
advertised the capping ability but did not enforce the limit, hence the
safelist.  I asked "Well can't we just trust vendor firmware?" and peals
of laughter erupted on the phone. ;)

If the user confusion is that Lenovo systems have ACPI power meters with
working power capping, you could consider adding Lenovo to the safelist.

That said, the message is misleading.  It probably should have read:

"Power capping has not been verified to work on this platform.
Please ask the platform vendor email X to have it added to the list."

Alternately, you could remove the safelisting entirely and assume that
if the firmware is malicious there are far more evil things it will try.
Seeing as IBM AEM is a decade old I doubt it's protecting much now.

But /me shrugs and says, "eh, good enough".  Also, nice to hear from you
& lcm again. :)

Reviewed-by: Darrick J. Wong <darrick.wong@...cle.com>

--D

> 
> Patch: Remove error message because it is generally misinterpreted. A replacement
> for the message is not necessary.
> 
> Signed-off-by: Max Asbock <masbock@...ovo.com>
> 
> diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c
> index 34e45b9..578e886 100644
> --- a/drivers/hwmon/acpi_power_meter.c
> +++ b/drivers/hwmon/acpi_power_meter.c
> @@ -693,11 +693,8 @@ static int setup_attrs(struct acpi_power_meter_resource *resource)
>  	}
>  
>  	if (resource->caps.flags & POWER_METER_CAN_CAP) {
> -		if (!can_cap_in_hardware()) {
> -			dev_err(&resource->acpi_dev->dev,
> -				"Ignoring unsafe software power cap!\n");
> +		if (!can_cap_in_hardware())
>  			goto skip_unsafe_cap;
> -		}
>  
>  		if (resource->caps.configurable_cap)
>  			res = register_attrs(resource, rw_cap_attrs);
> 
> 
>