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]
Date:	Sat, 03 Jan 2009 18:14:44 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Rob Landley <rob@...dley.net>
CC:	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.

Rob Landley wrote:
> 
>> The new patches have *more* environmental
>> dependencies than that ever did.
> 
> Could you please be a little more specific?
> 

In this case, you're assuming that every version of every shell this is
going to get involved with is going to do math correctly with the
requisite precision, which is nowhere guaranteed, I'm pretty sure.

>> Third, if someone actually cares to do it right, I have a smallish
>> bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
>> might be a starting point.
> 
> This doesn't _need_ bignum support.  It maxes out around 72 bits and the 
> _result_ can't use more than about $SHIFT bits because you're dividing by the 
> amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit 
> division on the top (it has to fit), and then do the same division on the 
> appropriate shifted remainder, and combine the results.  This is easy because 
> when the shift _is_ 32 bits or more, the bottom 32 bits all have to be zeroes 
> so you don't even have to mask and add, just shift the remainder left 32 bits 
> so you can continue the divide.
> 
> Pulling out perl isn't always a good alternative to thinking about the 
> problem.
> 

Neither is open-coding a bignum operation instead of relying on an
existing, validated implementation.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ