linux-kernel - Re: [PATCH 1/3] efi/cper, cxl: Decode CXL Component Events General Media Event Record

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: <65302871abbc6_725832944e@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Wed, 18 Oct 2023 11:48:17 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Ard Biesheuvel <ardb@...nel.org>,
        Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
CC:     Ira Weiny <ira.weiny@...el.com>, <linux-efi@...r.kernel.org>,
        <linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Alison Schofield <alison.schofield@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        "Dan Williams" <dan.j.williams@...el.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Yazen Ghannam <yazen.ghannam@....com>
Subject: Re: [PATCH 1/3] efi/cper, cxl: Decode CXL Component Events General
 Media Event Record

Ard Biesheuvel wrote:
> On Tue, 17 Oct 2023 at 22:52, Smita Koralahalli
> <Smita.KoralahalliChannabasappa@....com> wrote:
> >
> > Hi Ira,
> >
> > On 10/12/2023 5:25 PM, Ira Weiny wrote:
> > > Smita Koralahalli wrote:
> > >> Add support for decoding CXL Component Events General Media Event Record
> > >> as defined in CXL rev 3.0 section 8.2.9.2.1.1.
> > >>
> > >> All the event records as defined in Event Record Identifier field of the
> > >> Common Event Record Format in CXL rev 3.0 section 8.2.9.2.1 follow the
> > >> CPER format for representing the hardware errors if reported by a
> > >> platform.
> > >>
> > >> According to the CPER format, each event record including the General
> > >> Media is logged as a CXL Component Event as defined in UEFI 2.10
> > >> Section N.2.14 and is identified by a UUID as defined by Event Record
> > >> Identifier field in Common Event Record Format of CXL rev 3.0 section
> > >> 8.2.9.2.1. CXL Component Event Log field in Component Events Section
> > >> corresponds to the component/event specified by the section type UUID.
> > >>
> > >> Add support for decoding CXL Component Events as defined in UEFI 2.10
> > >> Section N.2.14 and decoding Common Event Record as defined in CXL rev 3.0
> > >> section 8.2.9.2.1.
> > >>
> > >> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
> > >
> > > [snip]
> > >
> > >> +
> > >> +/*
> > >> + * Compute Express Link Common Event Record
> > >> + * CXL rev 3.0 section 8.2.9.2.1; Table 8-42
> > >> + */
> > >> +struct common_event_record {
> > >> +    u8 identifier[16];
> > >
> > > I interpreted the CPER structure as not having this identifier here.
> > >
> > >  From Section N.2.14:
> > >
> > > "For the CXL Component Event Log: Refer to the Common Event Record field
> > > (Offset 16) of the Events Record Format for each CXL component."
> > >
> > > This implies that the data coming from the CPER record starts at length.
> >
> > Thanks for pointing this out. According to Spec, you are right. Our
> > records did show up the identifier. Hence, I added that field. We should
> > probably fix it from our end.
> >
> > Meanwhile, I'm taking a look at your patches.
> >
> 
> Thanks
> 
> Once you've compared notes, can you please let me know how to proceed?
> I will not consider Ira's patches or yours for merging before that.

Ard, I have a higher-level question. If these CPER records get routed to
the CXL subsystem to be emitted by code that is shared with the
native-driver record-retrieval mechanism, is there still motivation to
parse and emit them to the kernel log in the EFI code?

The difference with these CXL memory error records vs other records like
CPER_SEC_PLATFORM_MEM is that the record contains device-local addresses
that need translation to be of use to other system-software and that
translation needs topology information that the CXL subsystem has
enumerated.

So, my proposal is that the final form of this enabling would emit the
record for CXL to consume, but otherwise not emit it via printk().