linux-kernel - Re: PATCH [0/3]: Simplify the kernel build by removing perl.

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: <49602248.1010506@zytor.com>
Date:	Sat, 03 Jan 2009 18:43:20 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jamie Lokier <jamie@...reable.org>
CC:	Rob Landley <rob@...dley.net>,
	Leon Woestenberg <leon.woestenberg@...il.com>,
	Embedded Linux mailing list <linux-embedded@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

H. Peter Anvin wrote:
> Jamie Lokier wrote:
>> Related query:
>>
>> Does the Perl script being replaced use 64-bit arithmetic?  Because
>> many Perl installations only do 32-bit arithmetic.
>>
>> If the Perl version works in 32-bit arithmetic, why does the shell
>> version not do the same thing?
>>
> 
> The Perl version uses Math::BigInt, a Perl standard module (with a
> canned-values fallback for ancient or minimal Perl installations) to do
> arbitrary precision arithmetic.
> 
> The original version also produced constants that could be used with
> 64-bit values, but since gcc doesn't support 128-bit arithmetic on
> 32-bit platforms (gcc *does* support 128-bit arithmetic on 64-bit
> platforms) we didn't end up using it and removed them, although the code
> to generate them can still be activated.
> 

I should point out that we really *should* use same kind of techniques
on 64 bits as well.  Even though the likelihood of overflow is much less
there (and the use of the LCD reduces it further) it is nonzero.
However, the places that were most seriously affected were all operating
on 32-bit input (int), and therefore the overflow-free 64-bit code never
got written.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/