linux-kernel - Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem

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]

Date: Mon, 6 May 2024 12:30:14 +0200
From: Borislav Petkov <bp@...en8.de>
To: Shiju Jose <shiju.jose@...wei.com>
Cc: "linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"dave@...olabs.net" <dave@...olabs.net>,
	Jonathan Cameron <jonathan.cameron@...wei.com>,
	"dave.jiang@...el.com" <dave.jiang@...el.com>,
	"alison.schofield@...el.com" <alison.schofield@...el.com>,
	"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>,
	"ira.weiny@...el.com" <ira.weiny@...el.com>,
	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"david@...hat.com" <david@...hat.com>,
	"Vilas.Sridharan@....com" <Vilas.Sridharan@....com>,
	"leo.duran@....com" <leo.duran@....com>,
	"Yazen.Ghannam@....com" <Yazen.Ghannam@....com>,
	"rientjes@...gle.com" <rientjes@...gle.com>,
	"jiaqiyan@...gle.com" <jiaqiyan@...gle.com>,
	"tony.luck@...el.com" <tony.luck@...el.com>,
	"Jon.Grimm@....com" <Jon.Grimm@....com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"rafael@...nel.org" <rafael@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"naoya.horiguchi@....com" <naoya.horiguchi@....com>,
	"james.morse@....com" <james.morse@....com>,
	"jthoughton@...gle.com" <jthoughton@...gle.com>,
	"somasundaram.a@....com" <somasundaram.a@....com>,
	"erdemaktas@...gle.com" <erdemaktas@...gle.com>,
	"pgonda@...gle.com" <pgonda@...gle.com>,
	"duenwen@...gle.com" <duenwen@...gle.com>,
	"mike.malvestuto@...el.com" <mike.malvestuto@...el.com>,
	"gthelen@...gle.com" <gthelen@...gle.com>,
	"wschwartz@...erecomputing.com" <wschwartz@...erecomputing.com>,
	"dferguson@...erecomputing.com" <dferguson@...erecomputing.com>,
	"wbs@...amperecomputing.com" <wbs@...amperecomputing.com>,
	"nifan.cxl@...il.com" <nifan.cxl@...il.com>,
	tanxiaofei <tanxiaofei@...wei.com>,
	"Zengtao (B)" <prime.zeng@...ilicon.com>,
	"kangkang.shen@...urewei.com" <kangkang.shen@...urewei.com>,
	wanghuiqiang <wanghuiqiang@...wei.com>,
	Linuxarm <linuxarm@...wei.com>
Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem

On Thu, Apr 25, 2024 at 06:11:13PM +0000, Shiju Jose wrote:
> It is expected to have multiple RAS-specific functionalities other
> than scrubbing  in long run.  Most of the classes in the kernel found
> as  /sys/class/<class-name>/<class-name>X/
> 
> If not, however /sys/class/ras/<module -name>X/<feature> is more
> suitable because there are multiple device instances such as cxl
> devices with scrub control feature.  For example,
> /sys/class/ras/cxlX/scrub

Make it as user-friendly as possible. cxlX is not as user-friendly as

/sys/class/ras/cxl/<mem_accelerator>
		  /<fancy_bla_thing>

and so on.

Yes, you can introduce a special category .../ras/cxl/ if there are
multiple cxl devices which have RAS functionality on them.

> Presently underlying hw driver does the check. I think this will
> become more complex if does in the common rate_store() if we have to
> check against either a list of possible rates or min and max rates.

Ok.

> >> +DEVICE_ATTR_RW(enable_background);
> >> +DEVICE_ATTR_RO(name);
> >> +DEVICE_ATTR_RW(rate);
> >> +DEVICE_ATTR_RO(rate_available);
> >
> >static

Forgot one.

> This is the ras instance id (X) used for scrub control feature, /sys/class/ras/rasX/scrub/

Yeah, as discussed  above.

> >> +static int __init memory_scrub_control_init(void) {
> >> +	return class_register(&scrub_class); }
> >> +subsys_initcall(memory_scrub_control_init);
> >
> >You can't just blindly register this thing without checking whether there are even
> >any hw scrubber devices on the system.
>
> I think it happens only when a dependent module as autoloaded based
> on a scrub device existing with exception of memory scrub control
> built in and who would build this in?

You think or you know?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette