linux-kernel - Re: [PATCH] mm/hugetlb: ensure signedness of large numbers

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: <1577583097.5661.6.camel@HansenPartnership.com>
Date:   Sat, 28 Dec 2019 17:31:37 -0800
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     isidentical <batuhanosmantaskaya@...il.com>
Cc:     Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/hugetlb: ensure signedness of large numbers

On Sat, 2019-12-28 at 13:33 +0300, isidentical wrote:
> This change introduces a sanitity helper for
> numbers that are larger than 2^5.

What's the rationale for this ... i.e. what problem are you trying to
solve?  left to its own devices, gcc will assume int size for all
literals, so 34<<26 doesn't appear to have a problem, except that it
will be sign extended as a negative number into a 64 bit variable. 
However, it's designed use is for an int flags in mmap, so its current
definition seems to be fine.

> Signed-off-by: isidentical <batuhanosmantaskaya@...il.com>
> ---
>  include/uapi/asm-generic/hugetlb_encode.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/asm-generic/hugetlb_encode.h
> b/include/uapi/asm-generic/hugetlb_encode.h
> index b0f8e87235bd..42c06c62ae17 100644
> --- a/include/uapi/asm-generic/hugetlb_encode.h
> +++ b/include/uapi/asm-generic/hugetlb_encode.h
> @@ -31,6 +31,6 @@
>  #define HUGETLB_FLAG_ENCODE_512MB	(29 <<
> HUGETLB_FLAG_ENCODE_SHIFT)
>  #define HUGETLB_FLAG_ENCODE_1GB		(30 <<
> HUGETLB_FLAG_ENCODE_SHIFT)
>  #define HUGETLB_FLAG_ENCODE_2GB		(31 <<
> HUGETLB_FLAG_ENCODE_SHIFT)
> -#define HUGETLB_FLAG_ENCODE_16GB	(34 <<
> HUGETLB_FLAG_ENCODE_SHIFT)
> +#define HUGETLB_FLAG_ENCODE_16GB	(UINT32_C(34) <<
> HUGETLB_FLAG_ENCODE_SHIFT)

And if there is a literal problem here, it can't be solved like this:
UINT32_C is a Cism which has no analogue in the kernel because we don't
pull in the /usr/include headers where it is defined.  Usually in the
kernel we solve this by making the literal type explicit, like 34U, but
as I said above, I don't see a problem that this would solve.

James