linux-kernel - Re: [PATCH v1 1/1] cxl/hdm: Verify HDM decoder capabilities after parsing

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: <67c24a88bb358_1a7729481@dwillia2-xfh.jf.intel.com.notmuch>
Date: Fri, 28 Feb 2025 15:45:12 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Alison Schofield <alison.schofield@...el.com>, Li Ming
	<ming.li@...omail.com>
CC: <dave@...olabs.net>, <jonathan.cameron@...wei.com>,
	<dave.jiang@...el.com>, <vishal.l.verma@...el.com>, <ira.weiny@...el.com>,
	<dan.j.williams@...el.com>, <linux-cxl@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 1/1] cxl/hdm: Verify HDM decoder capabilities after
 parsing

Alison Schofield wrote:
> On Fri, Feb 28, 2025 at 10:47:12AM +0800, Li Ming wrote:
> > On 2/28/2025 5:47 AM, Alison Schofield wrote:
> > > On Thu, Feb 27, 2025 at 06:32:51PM +0800, Li Ming wrote:
> > >> devm_cxl_setup_hdm() only checks if decoder_count is 0 after parsing HDM
> > >> decoder capability, But according to the implementation of
> > >> cxl_hdm_decoder_count(), cxlhdm->decoder_count will never be 0.
> > > How does a check against the spec maximums benefit this driver? Is there
> > > a bad path we avoid by checking and quitting at this point.
> > 
> > 
> > My understanding is that no a bad path on driver side if the decoder_count is greater than the maximum number spec defines.
> > 
> > Driver just allocates cxl decoders on the port based on the value of decoder_count. But I am not sure if hardware will have other potential problems when it didn't follow the spec.
> 
> I had the general thought that the driver is not responsible for
> compliance checking the device, unless it affects function. Excessive
> decoder_count's sound like they cause needless allocations, so let's
> stop doing that - as best we can. 

Only if we see a device in the wild that causes an actual problem.
Otherwise this is a losing theoretical game of adding checks for things
that will likely never be violated. The way to address devices that
violate spec expectations *and* cause end user visible pain is to add
quirks. The allocation of a few extra decoders is does not amount to
that standard.

Lets not add checks for benign issues "just because", or "just in case".
If the check is cheap and we need to do it for the driver's own internal
sanity, fine, but if it's just being strict for strictness sake, please
no.