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: <65412f5defc6d_2e75b2948@iweiny-mobl.notmuch>
Date:   Tue, 31 Oct 2023 09:46:22 -0700
From:   Ira Weiny <ira.weiny@...el.com>
To:     Dan Williams <dan.j.williams@...el.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Jonathan Cameron <jonathan.cameron@...wei.com>,
        Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
CC:     Yazen Ghannam <yazen.ghannam@....com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Dave Jiang <dave.jiang@...el.com>,
        Alison Schofield <alison.schofield@...el.com>,
        Vishal Verma <vishal.l.verma@...el.com>,
        "Ard Biesheuvel" <ardb@...nel.org>, <linux-efi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-cxl@...r.kernel.org>,
        Ira Weiny <ira.weiny@...el.com>
Subject: RE: [PATCH RFC v2 2/3] firmware/efi: Process CXL Component Events

Dan Williams wrote:
> Ira Weiny wrote:

[snip]

> > 
> > diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> > index 35c37f667781..d6415c94d584 100644
> > --- a/drivers/firmware/efi/cper.c
> > +++ b/drivers/firmware/efi/cper.c
> > @@ -607,6 +607,22 @@ cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata
> >  			cper_print_prot_err(newpfx, prot_err);
> >  		else
> >  			goto err_section_too_small;
> > +	} else if (guid_equal(sec_type, &CPER_SEC_CXL_GEN_MEDIA) ||
> > +		   guid_equal(sec_type, &CPER_SEC_CXL_DRAM) ||
> > +		   guid_equal(sec_type, &CPER_SEC_CXL_MEM_MODULE)) {
> > +		struct cper_cxl_event_rec *rec = acpi_hest_get_payload(gdata);
> > +
> > +		printk("%ssection type: CXL Event\n", newpfx);
> 
> I would say that since this is going to be hanlded elsewhere the kernel
> log can stay silent.

Yep, bad cargo cult.

Removed.

[snip]

> > +
> > +int register_cxl_cper_notifier(struct notifier_block *nb)
> > +{
> > +	return blocking_notifier_chain_register(&cxl_cper_chain_head, nb);
> > +}
> > +EXPORT_SYMBOL(register_cxl_cper_notifier);
> 
> I think this should be EXPORT_SYMBOL_NS_GPL(..., CXL) since I can't
> imagine a third-party driver use case for this.

Good point.  Done.

[snip]

> >  
> > +/*
> > + * Event log size adjusted for CPER
> > + *
> > + * Base table from CXL r3.0 Table 8-42: (30h + 50h)
> > + * For lack of UUID: - 10h
> > + *
> > + * (30h + 50h) - 10h = 70h
> > + */
> > +#define CPER_CXL_COMP_EVENT_LOG_SIZE 0x70
> > +#define CPER_CXL_DEVICE_ID_VALID		BIT(0)
> > +#define CPER_CXL_DEVICE_SN_VALID		BIT(1)
> > +#define CPER_CXL_COMP_EVENT_LOG_VALID		BIT(2)
> > +struct cper_cxl_event_rec {
> > +	struct {
> > +		u32 length;
> > +		u64 validation_bits;
> > +		struct {
> > +			u16 vendor_id;
> > +			u16 device_id;
> > +			u8 func_num;
> > +			u8 device_num;
> > +			u8 bus_num;
> > +			u16 segment_num;
> > +			u16 slot_num; /* bits 2:0 reserved */
> > +			u8 reserved;
> > +		} device_id;
> > +		struct {
> > +			u32 lower_dw;
> > +			u32 upper_dw;
> > +		} dev_serial_num;
> > +	} hdr;
> > +
> > +	u8 comp_event_log[CPER_CXL_COMP_EVENT_LOG_SIZE];
> 
> Rather than define CPER_CXL_COMP_EVENT_LOG_SIZE I would prefer that CXL
> and EFI share a common struct definition for these common fields.
> 
> That would also remove the need for BUILD_BUG_ON() since they literally
> can not disagree on the size in that case.

I don't know if we discussed this publicly or internally but I had
versions which lifted the CXL structs to the core.  But your opinion at
that time was it was not needed.

Looking at it again I might get away with the main event record struct
defined here.  But it is kind of odd to be in efi.h IMO.

> 
> > +};
> > +#define CPER_CXL_REC_LEN(rec) (rec->hdr.length - sizeof(rec->hdr))
> > +
> > +enum cxl_cper_event {
> > +	CXL_CPER_EVENT_GEN_MEDIA,
> > +	CXL_CPER_EVENT_DRAM,
> > +	CXL_CPER_EVENT_MEM_MODULE,
> > +};
> 
> It follows from defining that common data structure above that this enum
> would be a generic CXL namespace that drops "_CPER_". I.e. the CPER
> notification handler and the native driver translate the event to this
> common generic sub-structure that gets emitted.

Ok this would be along the lines of promoting the definitions to a common
header.  Again I kept things pretty separate because it seemed that was
the direction you wanted to go.

I don't particularly like the memcpy which Smita flagged either.  But I
think this will require reworking the trace code to take a 'non-uuid'
structure equal to the payload 'comp_event_log' above.

Based on these comments I'll add some header promotion of common record
structures and see how it works out with the modified trace code.

Do you have any opinions on the name of the core header?

Ira

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ