linux-kernel - Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

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: <87d18vmgv6.fsf@e105922-lin.cambridge.arm.com>
Date:   Thu, 20 Jul 2017 13:29:17 +0100
From:   Punit Agrawal <punit.agrawal@....com>
To:     Borislav Petkov <bp@...e.de>
Cc:     <linux-kernel@...r.kernel.org>, <lorenzo.pieralisi@....com>,
        <sudeep.holla@....com>, <linux-acpi@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH 3/4] ACPI / APEI: Drop uninformative messages during boot

Hi Borislav,

Borislav Petkov <bp@...e.de> writes:

> On Thu, Jul 20, 2017 at 12:04:01PM +0100, Punit Agrawal wrote:
>> When booting an ACPI enabled system that does not provide the hardware
>> error source table (HEST), the ghes driver prints the following message
>> in the kernel log -
>> 
>> [    3.460067] GHES: HEST is not enabled!
>> 
>> which is not helpful.
>> 
>> The message is also output when HEST is explicitly disabled using kernel
>> command line parameter.
>> 
>> Drop this message. While we are touching this code, also drop similar
>> message when GHES is disabled using the module parameter.
>
> No.
>
> To the contrary, we want to know *why* GHES/HEST doesn't get enabled when
> booting. See
>
>   dba648300e89 ("ACPI / einj: Make error paths more talkative")
>
> for a good example why.

einj verbosity can't be used as a model here. einj by it's definition is
for development and testing. It can also be loaded as a module.

>
> If anything, you should do the total opposite patch and add more
>printks to the error paths so that it is obvious why GHES startup
>fails.

As mentioned in the commit log, the platform doesn't provide the HEST
(or any of the APEI tables for that matter). So it's not useful to see a
message complaining that HEST is not enabled. For such platforms, this
message at best adds no value and at worse gives the impression of
something gone wrong during boot.

I agree that where there is a genuine problem, relevant messages can
help to diagnose the problem. But what's printed now doesn't fit the
criteria.

Hope that makes sense.

Thanks,
Punit

>
> -- Regards/Gruss, Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)