Executing memory array on 64-bit architecture

[arngarden]

I have a piece of test code that looks like this:

int mem_set_permissions(void* src, int flags) {
    int pagesize = getpagesize();
    if (mprotect(((unsigned char *)src - ((long)src % pagesize)), 100, flags) == -1) {
        return 0;
    }
    return 1;
}
 
void test() {
    unsigned char *code = (unsigned char *)malloc(100);  
    mem_set_permissions(code, PROT_READ | PROT_WRITE | PROT_EXEC); 
    void(*codeptr)()=(void(*)())code;
 
    float f[4] __attribute__ ((aligned (16)));
    f[0]=f[1]=f[2]=f[3]=0;
    float **tmp = NULL;
 
    // set XMM[0] = 0
    *code++ = 0x0F;    //Opcode for MOVAPS = OF 28 
    *code++ = 0x28;    
    *code++ = 0x05;    //XMM[0]
    tmp = (float**)(code);
    *tmp = f;
    code += 4;
 
    *code++ = 0xc3; // OP-code for Return
 
    (codeptr)();
}
 

What it does is that it creates an array named code into which I put the opcodes for setting the SSE register XMM[0] = 0.
I then execute the array with the last call.

This works fine on 32-bit architectures (linux), I don't even have to use the mem_set_permissions instruction.
But on 64-bit it crashes on the execution of the array, (segmentation fault), even though I change
code += 4;
to
code += 8;

It works when I only run instructions like:
*code++ = 0xC3
But when I try the more complex instructions like XMM[0] = 0; it crashes.

I compile using gcc:
gcc test_perm_exec.c -o test_perm_exec

I would be very grateful for any help on this!

/Gustav

[weaknessforcats]

The first problem is that code is a pointer returned from malloc() and you are incrementing it therby losing the start of you allocation. Not good.

I would assign code to a temp pointer in increment it.

Secondly, the de-reference operatot an the incrment operator have the same precedence and are associated right to left. So *code++ will increment code and then de-reference it. I think you want to dereference code and then increment it so you should have ++(*code). Of course, using a temp variable instead of code.

[JosAH]

The first problem is that code is a pointer returned from malloc() and you are incrementing it therby losing the start of you allocation. Not good.

I would assign code to a temp pointer in increment it.

Secondly, the de-reference operatot an the incrment operator have the same precedence and are associated right to left. So *code++ will increment code and then de-reference it. I think you want to dereference code and then increment it so you should have ++(*code). Of course, using a temp variable instead of code.

Nope, the filling of the allocated memory was done alright; I don't speak 64 bits
Intel babble so I can't say anything else about it.

char foo[3];
char* p= foo;
*p++= 'h'; /* <--- this is what you were about */
*p++= 'i';
*p++= '\0';
puts(foo);
 

kind regards,

Jos

[arngarden]

Yes, I have been using this exact method for a long time without any problems, it is just now that I have switched to 64-bit that it crashes.

I can execute the array if I only fill it with instructions that only work on the SSE-registers, for example XMM0 = XMM0 + XMM1.
But the problem seems to be when I need to load values from memory, as in the given example..

[JosAH]

What happens if you apply the mem_set_permissions() function on that float
array as well?

kind regards,

Jos (just guessing)

[arngarden]

I have tried using it on the f-array, but that did not help unfortunately..

[JosAH]

I have tried using it on the f-array, but that did not help unfortunately..

... and what happens if the memory locations are part of that code array itself?

kind regards,

Jos

[arngarden]

I have checked that and the f-array are at a completely different location than the code-array, so they should not mix up.

[JosAH]

I have checked that and the f-array are at a completely different location than the code-array, so they should not mix up.

Yes I know but my question was what would happen if you'd put these four
floating point values in that code array as well? (at non-overlapping locations)

kind regards,

Jos

[weaknessforcats]

Nope, the filling of the allocated memory was done alright; I don't speak 64 bits
Intel babble so I can't say anything else about it.

Apparently, I don't speak 64-bits either. That code in 32-bit puts the value in the wrong array element.

[vkmgeek]

The exact instruction that is creating problem is
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x0000000000501010 in ?? ()
2: x/i $pc 0x501010: movaps 1741983040(%rip),%xmm0 # 0x68249d57
-----------------------------------------------------------
Now, the address content and address of variable f is as below
(gdb) x/12xb 0x501010
0x501010: 0x0f 0x28 0x05 0x40 0x8d 0xd4 0x67 0xff
0x501018: 0x7f 0x00 0x00 0xc3
(gdb) p &f
$4 = (float (*)[4]) 0x7fff67d48d40

Now if you convert (1741983040) into Hex, it is coming out (67d48d40) which is only 4bytes and it should have read 8 bytes.....

So seg fault is very much understandable.... But, how to fix this ?

[arngarden]

It seems like we have managed to solve the problem.
It turns out that on 64-bit system you cannot give a direct memory address in this way, you need use relative addressing and declare the f-vector globally.
It might also work if you change the last byte of the opcode to another value but that has not been tested properly yet...
Anyway, thanks for all the help!

[vkmgeek]

It seems like...

I will really appreciate if u can post your modified code for 64bit...
Or the changes tht u made...