netdev - Re: [PATCH RFC v1] rds: Expose feature parameters via sysfs and ELF note

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: <aEiYNk7JjdOnK-5M@char.us.oracle.com>
Date: Tue, 10 Jun 2025 16:41:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: allison.henderson@...cle.com, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, rds-devel@....oracle.com
Subject: Re: [PATCH RFC v1] rds: Expose feature parameters via sysfs and ELF
 note

On Tue, Jun 10, 2025 at 10:30:27PM +0200, Andrew Lunn wrote:
> > +What:		/sys/module/rds/parameters/rds_ioctl_set_tos
> > +Date:		Jun 2025
> > +Contact:	rds-devel@....oracle.com
> > +Description:
> > +		The RDS driver supports the mechanism to set on a socket
> > +		the Quality of Service.
> > +
> > +		The returned value is the socket ioctl number and this is read-only.
> 
> From this, can i imply that the IOCTL number has changed sometime in
> the past? That would be an ABI break, which is not good.

Not that I am aware of. But this is more of putting all of the different
exposed ABIs that exist in the driver instead of listing specific ones.

> 
> More likely, none of the IOCTL numbers have changed. All you need to
> know is if the file exists or not. So i would makes the files the same

Right..
> as /dev/null.

Not sure I follow. Make them the same a /dev/null? Meaning link them to
/dev/null when the module is loaded?
> 
> Also, these are not actually parameters to the module, so putting them
> in parameters seems confusing at best.

Right, that is the one part I was not sure about - another approach was
to create a new sysfs tree. But it would be more code as we have to
register all of that during initialization, while the module_param does it
very nicely.

> 
> I doubt this is the first time this problem has been addressed in the
> kernel. Maybe look at:
> 
> $ find /sys -name "*features*"
> /sys/kernel/security/apparmor/features
> /sys/kernel/cgroup/features
> 
> and see if you can copy/paste ideas/code from there. And also ask them
> if this was a good idea, or they say not don't do that, it was a bad
> idea, just call the IOCTL and test for ENOIOCTLCMD.

Good thinking - let me dig in that and also CC the authors of those to
get their feedback.

Thank you!
> 
> 	Andrew