4

I've recently been (relearning) lower level CS material and I've been exploring buffer overflows. I created a basic C program that has an 8-byte array char buffer[8];. I then used GDB to explore and disassemble the program and step through its execution. I'm on a 64-bit version of Ubuntu, and I noticed that my 8-byte char array is actually represented in 16 bytes in memory - the high order bits all just being 0.

E.g. Instead of 0xDEADBEEF 0x12345678 as I might expect to represent the 8 byte array, it's actually something like 0x00000000 0xDEADBEEF 0x00000000 0x12345678.

I did some googling and was able to get GCC to compile my program as a 32-bit program (using -m32 flag) - which resulted in the expected 8 bytes as normal.

I'm just looking for an unambiguous explanation as to why the 8-byte character array is represented in 16 bytes on a 64-bit system. Is it because the minimum word size / addressable unit is 16 bytes (64 bits) and GDB is simply printing based on an 8-byte word size?

Hopefully this is clear, but let me know if clarification is needed.

phuclv
  • 37,963
  • 15
  • 156
  • 475
DJSunny
  • 1,970
  • 3
  • 19
  • 27
  • 2
    Where is this `char buffer[8];`? Is it inside a `struct`? Is it on the stack? – Mysticial Jan 22 '13 at 05:23
  • Try to solve it by using #pragma pack – Uriel Frankel Jan 22 '13 at 05:24
  • 1
    FYI, 16 bytes is 128 bits. – Cornstalks Jan 22 '13 at 05:24
  • See [this question on the size of a char](http://stackoverflow.com/questions/881894/is-char-guaranteed-to-be-exactly-8-bit-long-in-c) – Dancrumb Jan 22 '13 at 05:24
  • It may be an optimisation. If the compiler can work out how you are using the array then it is allowed to store the object differently, as long as it does not affect the observable behaviour described in the C standard. – dreamlax Jan 22 '13 at 05:37
  • 6
    It would be clearer if you would just show us the exact code and the compiler version and options you used. All we can do is speculate. – Jeff Mercado Jan 22 '13 at 05:37
  • Are you sure it's `0x00000000 0xDEADBEEF 0x00000000 0x12345678` that doesn't make sense at all and would even break pointer arithmetic... Probably you are looking at two 32-bit registers in a 64bit representation or something. Check the values of &buffer[0], [1], [2], etc. – wich Jan 22 '13 at 05:40
  • @dreamlax this **would** break observable behavior as it would break pointer arithmetic, my guess would be that this is not the actual memory layout, but an interpretation issue – wich Jan 22 '13 at 05:42
  • 1
    @UrielFrankel #pragma pack does not come into it. The size of an array of T is n times the size of T, always (C99 6.5.3.4:6), and the size of char is one, always (C99 6.5.3.4:3). – Pascal Cuoq Jan 22 '13 at 06:02
  • @wich: It would only break observable behaviour if pointer arithmetic was involved. – dreamlax Jan 22 '13 at 07:13
  • Either you've got a broken compiler, or there's something wrong with your description. Can we see code? – Paul Hankin Jan 22 '13 at 07:45

1 Answers1

6

64bit systems are geared toward aligning all memory to 16 byte boundries (16 byte stack alignment is part of the System-V ABI), for stack allocations, there are two parts to this, firstly, the stack itself needs to be aligned, secondly any allocations then try to preserve that alignment.

This explains the first part as to why the 8 byte array becomes 16 bytes on the stack, as to why it gets split into two 8byte qwords, this is a little more difficult to tell, as you haven't provided any code (assembly or C) as to the use of this buffer. And trying to replicated this using mingw64 provides the 16 byte alignment, but not the funny layout you are seeing.

Of course, the other possibility stemming from the lack of ASM is that GDB is displaying 2xQWORD's even though its in fact 2xDWORD's (in other words, try using p/x (char[8]) to dump the contents...).

Necrolis
  • 25,836
  • 3
  • 63
  • 101