Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Aug 2013 12:40:40 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rafael's weekly report #10

Hi Rafael,

On Wed, Aug 21, 2013 at 6:47 AM, Rafael Waldo Delgado Doblas <
lord.rafa@...il.com> wrote:

> BTW The code is more than 7M and there is 1M of preinitialised data that I
> don’t know where it comes from (even if I have an empty main it stays
> there) and another mega that comes from something that shouldn't be
> initialised this is "volatile shared_buf_t M[16] SECTION("shared_dram");"
> the shared buffer. This means that we have 9784Bs occupied by the binary
> image I we will need at least reduce 3845Bs in order to reduce to TMTO 5.
> Any suggestion?
>

Are you looking at elf file with e-size? In my case it's bigger than *.srec
file that actually gets loaded on core. My suggestion is that you take look
at *.srec file contents (http://en.wikipedia.org/wiki/SREC_%28file_format%29)
and see what locations in local memory are used.
For bcrypt with e-size I get:
   text          data        bss        dec          hex    filename
  13114       6496        304      19914       4dca
parallella_e_bcrypt.elf

When I examine parallella_e_bcrypt,srec, addresses up to 0x37F0 in local
memory are used. After that shared buffer is initialized to zero (from
address 0x8F000000).

Katja

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

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