Writing an assembly code and want to make the ASLR (Address Space Layout Randomisation) complaint code.
armb8le platform (64 bit)
Previously was using LDR command to load the fork function as below:
ldr x4,=ASM_NAME(forkx)
From the ARM manual came to know that the for PC relative jump we need to use the ADR command and which will make it ASLR complaint. So now using ADRP command as below, chosen ADRP because of relative jump is more in this case, also ADR command used to give error.
adrp x4, ASM_NAME(forkx)
After doing this, now my binary generated the free of textrel segment and ASLR complaint.
But when i load the image it is getting crashed and traceback point to the function where this changes are done.
Also after loading x4 is getting used with load and store operation.
Please can anyone help in this? is there any problem in using these instruction like this?
Without a full example, I'm not sure if there is any advice I can offer. Perhaps look as the disassembly of the ADRP instruction to ensure that the offset points to a valid address? You can find the encoding of the instruction in the "Arm Arm":http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html
If you would like Arm to formally investigate the issue, please open a support case from the menu at the top of this page.
Thanks for the reply Ronam,
Able to debug more on this, following is the code that i have:
53 adrp x4,ASM_NAME(forkx)
54 ldr x1,[x4]
55 ldr x5, [x1, #savedSPFP]
Able to load the gdb and backtrace from the trace crash is as "ldr x5, [x1, #savedSPFP]". following is the analysis:
(gdb) info registers
x0 0x30a0 12448
x1 0x0 0
x2 0x7fdf1bf6b0 549203998384
x3 0x55ad57f898 367980443800
x4 0x55783dd000 367089537024
x5 0x0 0
x6 0x1 1
2. With ldr x5, [x1, #savedSPFP] is trying to access the addess x1+0x8 which means 0x0+0x8 = 0x8 and this address can not be accessed and get crashed.
(gdb) x/32 0x8
0x8: Cannot access memory at address 0x8
3. X1 we are populating as ldr x1,[x4], which is content of x4 means value in address 0x55783dd000. Which is ZERO as per GDB.
(gdb) x/32 0x55783dd000
0x55783dd000 <__be_tgRandomDS0Ptr+80>: 0x00000000 0x00000000 0x00000000 0x00000000
4. Address we are getting from the instruction adrp x4,ASM_NAME(forkx) , here We are loading forkx structure address to x4, if we see the address of the forkx we can see below:
(gdb) print &forkx
$13 = (sprocess * __be *) 0x55783dd5c0 <__be_forkx>
5. And we can see at this address following content:
(gdb) x/32 0x55783dd5c0
0x55783dd5c0 <__be_forkx>: 0x7f008000 0x60804d6c 0x04000000 0x00000000
So can you input why is x4 register is getting the value 0x55783dd000? is should have been0x55783dd5c0. Thanks.
Step #4 is correct in itself, the result of ADRP is a value with lower 12-bits set to zero, as its role is to calculate the base of a 4KB page.
However I don't understand the subsequent code and how it relates to calculating the address of fork. I don't know which compiler generated this code, or the source that generated it, but I'm not sure I can decipher from the info supplied.
Thanks for the input ronan, as you told it is expected behaviour, actually this code generated was wrong to get the forkx address we need to have 2 instructions:
add x4,x4, :lo12:ASM_NAME(forkx)
by adding the second instruction manually it is fine now. Thanks for the support.
Was this hand written assembler code, or compiler generated? If the compiler, could you provide a simple code sample that can be used to replicate this, so that it can be fixed.
This was a assembly code generated by intermittent translator that is used. i got only the assembly code generated to check the crash. have to check the tool doing this.