linux-kernel - Re: [patch] Avoid using hardcoded values in kernel/sys.c

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]

Date:	Mon, 17 Oct 2011 18:43:24 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Henrik Grindal Bakken <henribak@...co.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] Avoid using hardcoded values in kernel/sys.c

On Mon, Oct 17, 2011 at 6:33 PM, David Rientjes <rientjes@...gle.com> wrote:
>
> Right, I meant to pass the struct in and use sizeof(release->name), but I
> was under the impression that wouldn't count as a variable length array or
> be compiled as such by ISO99 standards because it's a constant expression
> (as the standard says is not variable length).

Yes, if it really were a constant expression of a valid length, that
would be fine. Passing in the struct itself would work, and then you
could do a sizeof of the array, instead of of the pointer to the
character array..

Except in this case it won't work. Because sometimes the struct is the
old one, sometimes it's the new one. So there is no well-defined
struct pointer to pass in. You can only pass in pointer-to-char and
the (variable) size.

Which is why it now just hardcodes it to 65, which is the largest
size. Not exactly "pretty", no. But no worse than using the variable
length array.

Yeah, there are tricks we could play. For example, we could turn that
override_release() into a macro that allocates the array in the
*caller*, where the length is known at compile time, and then pass in
that temporary pointer too. I considered it, but it seemed to be too
much work for too trivial a case. It's not like there are all that
many definitions of utsname, and they are all in <linux/utsname.h>.
It's unlikely that we'd ever add any bigger cases, but if we do, we'd
need to update the constant.

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/