[SOLVED] Strange length of auxiliary vector of executable file

[korisk]

Hi!

Could anybody answer me why auxiliary vector has different size from call to call of any executable?
(glibc 2.7, Linux 2.6.2

example:

#include <stdio.h>
#include <elf.h>

main(int argc, char* argv[], char* envp[]){
Elf32_auxv_t *auxv;
while(*envp++ != NULL); /*from stack diagram above: *envp = NULL marks end of envp*/
            
        for (auxv = (Elf32_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++)
        /* auxv->a_type = AT_NULL marks the end of auxv */
        {
//              ddif( auxv->a_type == AT_SYSINFO)
                printf("addr: %x type: %x is: 0x%x\n", (int)auxv, auxv->a_type, auxv->a_un.a_val);
        }
printf("\n (int)argv[0] - addr = %x - %x = %x\n",(int)argv[0], (int)auxv, (int)argv[0] - (int)auxv);
}

[cgrebeld]

printf("\n (int)argv[0] - addr = %x - %x = %x\n",(int)argv[0], (int)auxv, (int)argv[0] - (int)auxv);

There are a few things wrong here. You are subtracting the wrong way, so you will be getting a negative number. You are casting pointers to ints, which may not be the same size (64 bit system). You should cast the pointer difference to an int instead:

printf("\n addr - argv = %p - %p = %d\n",argv, auxv, (int)((char**)auxv - argv));

[korisk]

There are a few things wrong here. You are subtracting the wrong way, so you will be getting a negative number. You are casting pointers to ints, which may not be the same size (64 bit system). You should cast the pointer difference to an int instead:

printf("\n addr - argv = %p - %p = %d\n",argv, auxv, (int)((char**)auxv - argv));

ok, thank you for the answer, but it measures just sizefo(auxv[], env[] and argv[]).

another example of mentioned phenomenon:

#include <stdio.h>
int main(int argc, char *argv[], char *env[]){
        char b = 1;
        register int c=0;
        register char *a = &b;
        while(1){
                *a++ = 1;
                printf("%x %x\n",(int)a,c++);
        }
        return 0;
}

number of iterations is differ from load to load.

[cgrebeld]

Ah, I though I was missing something... Seems like it might be a security feature?

[korisk]

i don't know, but it seems security is main goal of the behavior.
it's cloudy.

[korisk]

Solved.
Command
sysctl -w kernel.randomize_va_space=0
removes the phenomenon