linux-kernel - Re: [PATCH] cxl/acpi: Verify CHBS consistency

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] [day] [month] [year] [list]

Date:   Tue, 21 Jun 2022 16:04:43 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Davidlohr Bueso <dave@...olabs.net>,
        Dan Williams <dan.j.williams@...el.com>
CC:     <linux-cxl@...r.kernel.org>, <alison.schofield@...el.com>,
        <bwidawsk@...nel.org>, <ira.weiny@...el.com>,
        <vishal.l.verma@...el.com>, <a.manzanares@...sung.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cxl/acpi: Verify CHBS consistency

Davidlohr Bueso wrote:
> On Tue, 21 Jun 2022, Dan Williams wrote:
> 
> >For cxl_port objects this happens "for free" as a side effect of the:
> >
> >        crb = devm_cxl_iomap_block(dev, port->component_reg_phys,
> >                                   CXL_COMPONENT_REG_BLOCK_SIZE);
> >
> >...call in devm_cxl_setup_hdm(), where it tries to exclusively claim the
> >component register block for that cxl_port driver instance.
> 
> Fair enough, I had noticed this.
> 
> >
> >I.e. if the CHBS provides overlapping / duplicated ranges the failure is
> >localized to the cxl_port_probe() event for that port, and can be
> >debugged further by disabling one of the conflicts.
> 
> Ok. Although imo it does make sense for failing directly in the cxl_acpi
> driver at an early stage instead of bogusly passing it down the hierarchy.

You could make that argument for almost any resource range advertised to
the kernel. The expected place where they finally collide is at
request_region() time.

> So is a v2 still worth it without this check?

I do notice that you also added a CXL 1.1 version check. That seems
useful to break out, but probably needs a rationale for what that means
for CXL 2.0 device on CXL 1.1 host compatibility. So a patch per new
CHBS consistency check is my preference, but I think only the CXL 1.1
check is still open.