Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 28 Nov 2011 02:24:57 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: .bss size in -jumbo

2011-11-28 02:07, Solar Designer wrote:
> .bss in 1.7.8-jumbo-8 grew to 140 MB in a 64-bit build with OpenMP:
...
> I think at least top 5 of these (or maybe 7 or 9) should be changed to
> allocate their memory dynamically, like 1.7.9 does in MD5_fmt.c and
> BSDI_fmt.c.  (1.7.9's DES_fmt.c and c3_fmt.c also use dynamic memory
> allocation, but in format-specific ways.  BF_fmt.c's saved_key[] is
> relatively small (the number of buffered keys is low because this hash
> is so slow), and BF_std.c puts its larger data structures on thread
> stacks (just one instance per thread).)

Yes, this was already something I was planning to have a look at, sooner
or later. I really liked the "trick" you used in MD5_fmt.c:


static char (*saved_key)[PLAINTEXT_LENGTH + 1];
...
saved_key = mem_alloc_tiny(
    sizeof(*saved_key) * fmt_MD5.params.max_keys_per_crypt,
    MEM_ALIGN_CACHE);


It took me half a day to understand why it works. It's a very convenient
way of writing it!

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ