linux-kernel - Re: [RFC][PATCH] lib/string: introduce sysfs_strncpy() and sysfs

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]

Message-ID: <20180822051314.GB6876@jagdpanzerIV>
Date:   Wed, 22 Aug 2018 14:13:14 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>, Martin Wilck <mwilck@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [RFC][PATCH] lib/string: introduce sysfs_strncpy() and
 sysfs_strlcpy()

Hi,

On (08/21/18 14:43), Rasmus Villemoes wrote:
> > I think that sysfs input is always properly NULL-terminated. It may or
> > may not contain \n, but \0 is expected to be there.
> 
> Maybe. But it shouldn't hurt to make it accept a src size (the caller
> can always pass -1 is he's sure the input is nul-terminated) - I'm
> thinking a new interface might also have uses outside sysfs.

Makes sense.

> > E.g.
> > 	channel_dimm_label_store()
> > 	dimmdev_label_store()
> > 	pmbus_add_label()
> > 	axp20x_store_attr()
> > 	cmdline_store()
> 
> Hm, do any of those actually want the skipping of leading whitespace?

Hm, that's a good question. I'd probably say "mostly yes". The input
usually goes to strcmp/strcpy/strtol/etc. But we don't have to trim
leading whitespaces and can just let the driver error out [hopefully
the driver has a well tested error-out path].

> pmbus_add_label doesn't even seem to kill a trailing newline?

Sorry, I think pmbus_add_label() made it to the list by mistake. It doesn't
appear to be a ->store() callback.

> It's probably hard to create one interface that will work for all cases.

Agreed, that's why I targeted sysfs input data only ;)

> Dunno, looking at your examples above I'm a bit more skeptical that
> there is a lot of common ground. But of course there are hundreds of
> other store callbacks, so surely one can simplify some with a new helper.

Yep.

	-ss