{"id":290,"date":"2025-12-22T14:32:11","date_gmt":"2025-12-22T14:32:11","guid":{"rendered":"https:\/\/haco.club\/?p=290"},"modified":"2025-12-22T14:32:11","modified_gmt":"2025-12-22T14:32:11","slug":"memory-layoutglobal-data-code-stack-heap-etc-with-tls","status":"publish","type":"post","link":"https:\/\/haco.club\/?p=290","title":{"rendered":"Memory Layout(global data, code, stack, heap, etc) with TLS"},"content":{"rendered":"\n

On AArch64 (ARM64), the memory layout for Thread Local Storage (TLS) follows TLS Variant 1<\/strong>.<\/p>\n\n\n\n

This is distinct from x86_64 (which uses Variant 2). The key difference is the location of the TLS data relative to the thread pointer.<\/p>\n\n\n\n

1. The High-Level View (Process Memory)<\/h3>\n\n\n\n

For a standard Linux process on AArch64, the memory is laid out as follows (from Low Address to High Address):<\/p>\n\n\n\n

      +----------------------+  <-- High Address (e.g., 0x0000ffff...)\n      |        Stack         |  (Main Thread Stack, grows DOWN)\n      +----------------------+\n      |          ...         |\n      |   Memory Mapping     |  <-- Shared Libraries, Mapped Files\n      |      (mmap region)   |      AND Secondary Thread Stacks\/TLS\n      |          ...         |\n      +----------------------+\n      |         Heap         |  (Grows UP)\n      +----------------------+\n      |         BSS          |  (Uninitialized Global Data)\n      +----------------------+\n      |         Data         |  (Initialized Global Data)\n      +----------------------+\n      |         Text         |  (Code \/ Instructions)\n      +----------------------+  <-- Low Address (e.g., 0x00000000...)<\/code><\/pre>\n\n\n\n
2. The Detailed TLS Layout (Variant 1)<\/h3>\n\n\n\n
In Variant 1<\/strong> (used by ARM\/AArch64), the Thread Pointer points to the Thread Control Block (TCB)<\/strong>, and the actual TLS variables are located at positive offsets<\/strong> (higher addresses) after the TCB.<\/p>\n\n\n\n
tpidr_el0<\/code><\/strong> points exactly here: [ TCB Start ]<\/code><\/p>\n\n\n\n
      +---------------------------+\n      |  TLS for Shared Libs      |\n      |  (Loaded at startup)      |\n      +---------------------------+\n      |  TLS for Executable       |  <-- Your \"__afl_prev_loc\" is here\n      |  (The \"Static TLS\")       |\n      +---------------------------+ <--- Offset 16 (Start of TLS Data)\n      |         TCB               |\n      |  (Thread Control Block)   |  <--- 16 bytes reserved\n      +---------------------------+ <--- tpidr_el0 points HERE<\/code><\/pre>\n\n\n\n
    \n
  • TCB (0 to 16 bytes):<\/strong> This small header contains internal linker data.\n
      \n
    • Offset 0:<\/strong> Pointer to DTV<\/strong> (Dynamic Thread Vector).<\/li>\n\n\n\n
    • Offset 8:<\/strong> Reserved (implementation specific).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
    • TLS Data (16+ bytes):<\/strong> The actual variables (like __afl_prev_loc<\/code>) start immediately after the TCB.<\/li>\n<\/ul>\n\n\n\n
      3. Main Thread vs. Secondary Threads<\/h3>\n\n\n\n
      The physical placement of this “TLS Block” differs depending on which thread it is.<\/p>\n\n\n\n
      A. Secondary Threads (created via pthread_create<\/code>)<\/h4>\n\n\n\n
      When you create a thread, glibc<\/code> allocates a single large chunk of memory (via mmap<\/code>) to hold both<\/strong> the stack and the TLS.<\/p>\n\n\n\n
      High Address\n   ^  +-------------------------+\n   |  |   Gap \/ Padding         |\n   |  +-------------------------+\n   |  |   TLS Data              |\n   |  +-------------------------+\n   |  |   TCB (16 bytes)        | <--- tpidr_el0 points here\n   |  +-------------------------+\n   |  |                         |\n   |  |      Thread Stack       |\n   |  |      (Grows Down)       |\n   |  |           |             |\n   |  |           v             |\n   |  +-------------------------+\n   |  |      Guard Page         | (Protected to catch overflows)\n   +  +-------------------------+\nLow Address<\/code><\/pre>\n\n\n\n
        \n
      • Key Detail:<\/strong> The Stack is located below<\/strong> the TLS. If you overflow the stack (write too much), you hit the Guard Page. You typically do not<\/em> corrupt your own TLS (which is above you), though buffer overflows on<\/em> the stack could theoretically read\/write upwards.<\/li>\n<\/ul>\n\n\n\n
        B. The Main Thread<\/h4>\n\n\n\n
          \n
        • Stack:<\/strong> The main stack is allocated by the kernel at the very top of user memory.<\/li>\n\n\n\n
        • TLS:<\/strong> The Main Thread’s TLS is allocated by the dynamic linker (ld.so) early during startup. It is usually located near the heap or loaded libraries, separate<\/strong> from the main stack.<\/li>\n<\/ul>\n\n\n\n
          Why this matters for your AFL code<\/h3>\n\n\n\n
          In the assembly snippet you provided:<\/p>\n\n\n\n
            \n
          1. adrp ... _exit<\/code><\/strong>: It loads a global pointer to find the TLS offset.<\/li>\n\n\n\n
          2. blr<\/code> (Helper)<\/strong>: The helper calculates the offset.<\/li>\n\n\n\n
          3. add<\/code> \/ ldr<\/code><\/strong>: It adds that offset to tpidr_el0<\/code><\/strong>.<\/li>\n<\/ol>\n\n\n\n
            Because AArch64 is Variant 1<\/strong>, the offset returned by the helper will be a positive number<\/strong> (e.g., +24<\/code>). The code is effectively saying:
            “Take the address in tpidr_el0<\/code>, skip the 16-byte header, and go forward X bytes to find my variable.”<\/em><\/p>\n\n\n\n
            \n\n\n\n
            On AArch64 (ARM64) Linux (using glibc<\/code>), the memory layout differs significantly between the Main Thread<\/strong> and Secondary Threads<\/strong> (created via pthread_create<\/code>), even though they both use the same internal TCB structure.<\/p>\n\n\n\n
            Here is the detailed breakdown.<\/p>\n\n\n\n
            1. The Structure: struct pthread<\/code> (The TCB)<\/h3>\n\n\n\n
            Regardless of which thread it is, tpidr_el0<\/code> always points to the Thread Control Block (TCB)<\/strong>. In glibc<\/code>, this TCB is actually the header of a much larger structure called struct pthread<\/code>.<\/p>\n\n\n\n
            For AArch64 (TLS Variant 1), the layout at the pointer address is:<\/p>\n\n\n\n
            Memory Address: Low  ----------------------------------------> High\nPointer:        [ tpidr_el0 ]\nContents:       [ TCB Header ] [ Static TLS Data (App) ] [ Padding ]\nOffsets:        +0           +16                       +...<\/code><\/pre>\n\n\n\n
            Key Fields inside the TCB (struct pthread<\/code>):<\/strong><\/p>\n\n\n\n
              \n
            • offset 0x00 (dtv<\/code>):<\/strong> Pointer to the Dynamic Thread Vector<\/strong>. This tracks TLS variables for libraries loaded dynamically (via dlopen<\/code>).<\/li>\n\n\n\n
            • offset 0x08 (private<\/code>):<\/strong> Reserved (often used implementation-specific data).<\/li>\n\n\n\n
            • offset 0x28 (stack_guard<\/code>):<\/strong> (Approximate offset) The “Stack Canary” value. The compiler reads this value and puts it on the stack to detect buffer overflows.<\/li>\n\n\n\n
            • offset 0x30 (pointer_guard<\/code>):<\/strong> Used to XOR function pointers (like in setjmp<\/code>\/longjmp<\/code>) for security.<\/li>\n\n\n\n
            • Other fields:<\/strong> tid<\/code> (Thread ID), pid<\/code>, cleanup_jmp_buf<\/code>, joinid<\/code> (for pthread_join<\/code>), and scheduling priority.<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n
              2. Main Thread Layout<\/h3>\n\n\n\n
              The Main Thread is special because the Kernel creates its stack, but the Dynamic Linker (ld.so<\/code>) creates its TLS\/TCB. Therefore, they are usually in completely different memory regions<\/strong>.<\/p>\n\n\n\n
                \n
              • Stack:<\/strong> Located at the very top of the user address space (growing down).<\/li>\n\n\n\n
              • TCB\/TLS:<\/strong> Located near the executable code or Heap (growing up).<\/li>\n<\/ul>\n\n\n\n
                      [ High Address (e.g., 0x0000ffff...) ]\n      +-------------------------+\n      |       Main Stack        |  <-- Kernel allocates this\n      |      (Grows Down)       |\n      +-------------------------+\n      |          ...            |\n      |   (Gigabytes of Gap)    |\n      |          ...            |\n      +-------------------------+\n      |      Linked Libs        |\n      +-------------------------+\n      |     Main Thread TLS     |  <-- ld.so allocates this\n      |   [  Application TLS  ] |\n      |   [    TCB Header     ] |  <-- tpidr_el0 points here\n      +-------------------------+\n      [ Low Address ]<\/code><\/pre>\n\n\n\n
                \n\n\n\n
                3. Secondary Thread Layout (pthreads)<\/h3>\n\n\n\n
                When you call pthread_create<\/code>, glibc<\/code> allocates one contiguous block<\/strong> of memory (via mmap<\/code>) to hold everything<\/em> for that thread: the stack, the TCB, and the TLS.<\/p>\n\n\n\n
                This creates a “sandwich” layout where the TCB is effectively at the top<\/strong> of the stack space.<\/p>\n\n\n\n
                      [ High Address ]\n      +-------------------------+ <--- End of mmap'd block\n      |    Padding \/ Alignment  |\n      +-------------------------+\n      |    Static TLS Data      |  <-- \"Global\" variables for this thread\n      +-------------------------+\n      |       TCB Header        |  <-- tpidr_el0 points here\n      |    (struct pthread)     |\n      +-------------------------+\n      |                         |\n      |      Thread Stack       |  <-- Stack starts here and grows DOWN\n      |                         |\n      |           |             |\n      |           v             |\n      |                         |\n      +-------------------------+\n      |       Guard Page        |  <-- Protected page (SIGSEGV if stack overflows)\n      +-------------------------+ <--- Start of mmap'd block\n      [ Low Address ]<\/code><\/pre>\n\n\n\n
                Why does this matter for Fuzzing\/Exploitation?<\/h3>\n\n\n\n
                  \n
                1. Stack Overflow:<\/strong>\n
                    \n
                  • Main Thread:<\/strong> If you overflow the main stack, you hit unmapped memory (Crash) or legacy environment variables. You generally cannot<\/strong> overwrite the TCB\/TLS because it is gigabytes away.<\/li>\n\n\n\n
                  • Secondary Threads:<\/strong> If you overflow a secondary thread’s stack (going down), you hit the Guard Page. However, if you have a Buffer Over-read<\/strong> or an Underflow<\/strong> (writing upwards from a buffer on the stack), you are perilously close to the TCB.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                  • Targeting the TCB:<\/strong> If an attacker can write slightly above<\/em> the stack pointer in a secondary thread, they can overwrite:\n
                      \n
                    • stack_guard<\/code>:<\/strong> Bypassing stack canaries.<\/li>\n\n\n\n
                    • dtv<\/code>:<\/strong> Hijacking TLS variable lookups.<\/li>\n\n\n\n
                    • pointer_guard<\/code>:<\/strong> Bypassing pointer encryption.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
                      On AArch64 (ARM64), the memory layout for Thread Local Storage […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[30],"class_list":["post-290","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-binary"],"_links":{"self":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/290","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=290"}],"version-history":[{"count":1,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/290\/revisions"}],"predecessor-version":[{"id":292,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/290\/revisions\/292"}],"wp:attachment":[{"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=290"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=290"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=290"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}