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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 30 Aug 2020 00:37:15 +0100
From:   Alex Dewar <>
To:     unlisted-recipients:; (no To-header on input)
Cc:     Greg Kroah-Hartman <>,
        "Rafael J. Wysocki" <>,
        Christian Brauner <>,
        "David S. Miller" <>,
        Alex Dewar <>,
        Nayna Jain <>,
        Dan Williams <>,
        Sourabh Jain <>,
        Mauro Carvalho Chehab <>,
Subject: [PATCH RFC 0/2] simple sysfs wrappers for single values

Hi all,

I've noticed there seems to have been a fair amount of discussion around
the subject of possible helper methods for use in the context of sysfs
show methods (which I haven't had a chance to go through in detail yet
-- sorry!), so I thought I'd send out a couple of patches I've been
working on for this, in case it's of any interest to anyone.

My idea was to have a few simple wrappers for returning single values
via sysfs, as in theory that's how sysfs should be being used. This
isn't going to be usable for more complicated cases, but at least by
doing this we should be able to make it easier to direct the attention
of code checkers (either automated or the flesh-and-blood kind) towards
the potentially more problematic cases. Hopefully we should be able to
convert over many of the more trivial cases to these helpers using

For the number helper (sysfs_sprinti), I opted to go for a macro which
can handle short, int, ULL etc., though equally we could go for
differently named inline functions instead. Either way, I think
enforcing the type of input arguments and not allowing users to pass
format strings is the way to go. Even for e.g. "sprintf(buf, "%llu\n",
my_number)", there is the possibility that my_number could be of type
int and so mishandle negative values. Let's make it easy for maintainers
to review at a glance, without having to remember what type my_number
was declared as.

With the string helpers we can make sure that we aren't overflowing the
destination buffer, but I've also put in a check so that we don't read
beyond the end of the source buffer either, in the case that it's a
fixed-size array. So if we do have an automated changeover with
Coccinelle then we should make things safer too :-)

Anyway, I'm off to bed now but I'll check for messages in the morning.
Any feedback gratefully received!


Powered by blists - more mailing lists