linux-kernel - Re: [PATCH 0/8] Decode IA32/X64 CPER

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: <CAKv+Gu82+nPRhKSzAvTvwWqVPhi0zhjN4uC8_ZzA7HvBLEuuig@mail.gmail.com>
Date:   Sat, 24 Feb 2018 16:46:40 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Yazen Ghannam <Yazen.Ghannam@....com>
Cc:     linux-efi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Borislav Petkov <bp@...e.de>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH 0/8] Decode IA32/X64 CPER

Hi Yazen,

On 23 February 2018 at 20:03, Yazen Ghannam <Yazen.Ghannam@....com> wrote:
> From: Yazen Ghannam <yazen.ghannam@....com>
>
> This series adds decoding for the IA32/X64 Common Platform Error Record.
>
> Patch 1 fixes the IA32/X64 Processor Error Section definition to match
> the UEFI spec.
>
> Patches 2-8 add the new decoding. The patches incrementally add the
> decoding starting from the top-level "Error Section". Hopefully, this
> will make reviewing a bit easier compared to one large patch.
>
> The formatting of the field names and options is taken from the UEFI
> spec. I tried to keep everything the same to make searching easier.
>
> The patches were written to the UEFI 2.7 spec though the definition of
> the IA32/X64 CPER seems to be the same as when it was introduced in
> the UEFI 2.1 spec.
>
> Without basic decoding, users will be confused about what these
> "Hardware Errors" mean. So I'm requesting this set to be applied to the
> stable branches. This set applies to the v4.16. However, patch 2 will
> have a conflict on older branches, so I'll send this set again with the
> conflict fixed.
>

These patches look mostly fine to me, with the exception of some minor nits.

I can queue this for v4.17 if you respin it, but I am not sending 400
lines of brand new error record parsing code to Greg for inclusion in
-stable, so please drop the cc stable tags

Thanks,
Ard.