linux-kernel - Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output format

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: <525D26ED.9040602@linux.vnet.ibm.com>
Date:	Tue, 15 Oct 2013 16:58:45 +0530
From:	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To:	Tony Luck <tony.luck@...il.com>, Borislav Petkov <bp@...en8.de>
CC:	Chen Gong <gong.chen@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	Lance Ortiz <lance.ortiz@...com>
Subject: Re: [PATCH 7/8] ACPI, APEI, CPER: Cleanup CPER memory error output
 format

On 10/14/2013 10:42 PM, Tony Luck wrote:
> On Mon, Oct 14, 2013 at 3:36 AM, Borislav Petkov <bp@...en8.de> wrote:
>> On Mon, Oct 14, 2013 at 12:55:00AM -0400, Chen Gong wrote:
>>> Because most of data in CPER are empty or unimportant.
>>
>> It is not about whether it is important or not - the question is whether
>> changing existing functionality which someone might rely upon is a
>> problem here? Someone might be expecting exactly those messages to
>> appear in dmesg.
>
> Pulling in a couple more people who have been touching error reporting
> code in the last year or so (Hi Lance, Naveen ... feel free to drag more
> people to look at this thread).
>
> I prodded Chen Gong in to make this change because our console messages
> are way to verbose (and scary) for simple corrected errors.  There are 18
> fields in the memory error section (as of UEFI 2.4 ... more are likely to be
> added because there are issues that some of the 16-bit wide fields are too
> small to handle increased internal values in modern DIMMs).  Whether you
> print that one item per line, or a few very long lines - it is way
> more information
> than the average user will ever want or need to see.

I completely agree and I am all for bringing down the verbosity of GHES 
logs. In my testing, a corrected error event reported through GHES takes 
upwards of 10 lines, which is far too much. Perhaps a single line per 
GHES event with only a few important fields would be better?


Thanks,
Naveen

--
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/