What Does Clearing .bss Mean in Early Kernel Boot?

Forget C for a moment. Forget ELF. Forget the linker.

Here is what an x86-64 CPU does after reset, in caricature:

RIP = 0xfffffff0      ; instruction pointer points at reset vector
loop forever:
    fetch instruction at RIP
    decode
    execute (which may change RIP, registers, or memory)

That’s the whole loop. The CPU does not know which bytes are “code” and which are “data”. It doesn’t know which bytes are “supposed to be zero”. It will happily execute any byte sequence as an instruction. It will happily read any address and get whatever happens to be there. There is no validation, no zero-fill, no concept of “uninitialized memory.” Memory is just a giant array of bytes hooked up to a bus, and the CPU asks for byte number N and gets back whatever number N currently contains.

Power on a fresh-from-factory machine and DRAM contains essentially random bits. Reset a machine that was just running Linux and DRAM still contains Linux. The CPU does not care. It will read those bits.

So when you ask “what is .bss?” — the honest first answer is: the CPU has no idea. .bss is not a hardware concept. It is something invented entirely on the software side to solve a software problem.

The interesting question is which software problem.

This is the deep cut on the mental model. Both .data and .bss hold writable globals. Both end up in normal RAM, with normal read-write permissions, indistinguishable to the CPU once the program is running. So why are they two sections instead of one?

The answer is: .data has bytes the file must carry, .bss does not.

Consider:

int x = 0x12345678;       // .data
static char heap[16 * 1024 * 1024];  // .bss

The initial value of x is 0x12345678. There is no way to derive that value other than to write it into the file. The compiler emits four bytes into the .data section: 78 56 34 12. They live in the executable file. The loader copies them from disk into RAM.

The initial value of heap is 16 mebibytes of zeros. The compiler could emit 16 MiB of zero bytes into the .data section, and the loader would dutifully copy them from disk to RAM. But that’s absurd: the bytes carry no information. They’re just zero. Writing them into the file makes the file 16 MiB larger for no reason.

So someone, decades ago, said: let’s have a second section for writable globals whose initial value is known to be zero. We don’t need to store its bytes in the file. We just need to record its size and address. At load time, we’ll zero out that region of memory.

That’s .bss. The name historically comes from the IBM 7090 assembler instruction “Block Started by Symbol”, which referred to uninitialized blocks. The name stuck, the meaning shifted, and now .bss means “section whose contents are zero, materialized at load time, not stored in the file.”

In ELF, this is a section with type SHT_NOBITS. The section header says “this section occupies N bytes starting at address A” but it has no file offset and no bytes in the file. It is pure metadata.

If you ever run size some_program you’ll see:

   text    data     bss     dec     hex filename
   1234     567   89012   90813   162bd some_program

The bss column is purely a promise about memory. It costs nothing on disk.

This is the first piece of the mental model: .bss is a contract that says “at runtime, somebody will arrange for N bytes of zeros to exist at address A.” The file doesn’t carry those bytes. Someone has to fulfill the contract.

In a hosted environment, the OS fulfills it. In a freestanding kernel, you fulfill it. That’s the entire mystery of “clearing .bss” — it’s the kernel fulfilling its own runtime contract because nobody else will.

Take a step back. The CPU just wants an address. It will read or write any address with no concept of “section.” So why does any of this section infrastructure exist?

Three reasons, all on the software side:

Reason 1: Permissions.

Once you have a memory management unit (MMU), each page of memory can be marked read-only, read-write, executable, non-executable. Modern OSes use this aggressively: .text is read-only and executable, .rodata is read-only and non-executable, .data and .bss are read-write and non-executable. If the CPU tries to execute bytes in .data, it traps. If it tries to write to .rodata, it traps. This catches whole classes of bugs and entire classes of exploits.

But MMU permissions are per page, not per symbol. So the linker has to group symbols with the same desired permissions onto the same pages. Sections are how that grouping happens. The linker sorts symbols into sections by intended permission, the loader maps each section’s pages with the right permissions.

If there were no sections, the linker couldn’t tell the loader “make this range executable but not writable.” Everything would have to be either RWX (no protection at all) or you’d need per-symbol metadata, which would be enormous overhead.

Reason 2: File-size optimization.

Already covered: .bss exists separately from .data because zero bytes shouldn’t have to be stored on disk. This is also why some systems have things like .tdata and .tbss (for thread-local data — same split, same reason), or .note sections that carry metadata.

Reason 3: Tool ergonomics.

The linker needs to know what each chunk of bytes is for so it can:

• Resolve symbol references (jump to address X means “address of section Y plus offset Z”).
• Apply relocations correctly (a 32-bit PC-relative offset versus a 64-bit absolute address).
• Discard or merge sections (e.g., .gnu.linkonce style deduplication).
• Order sections sensibly (hot code together, cold code together).
• Produce debugging info that maps source lines to addresses.

So sections are a vocabulary the compiler uses to describe the bytes it emits, the linker uses to combine and place them, the loader uses to load and protect them, and debuggers and profilers use to understand the resulting binary.

None of this is the CPU’s business. The CPU just wants an address. The sections are how the toolchain ends up at the right addresses.

This is why “sections” feel so mysterious when you first encounter them: they’re an entirely software-side abstraction with no hardware correlate, but they shape how every binary on the system is laid out, and getting them wrong breaks programs in ways that are very hard to debug because the CPU happily executes the wrong-shaped bytes.

The linker script is where the abstract section model meets the concrete memory layout. Worth understanding because it’s where you see the boundary between “C’s view of the world” and “RAM’s view of the world.”

A minimal kernel linker script for x86-64:

ENTRY(_start)

SECTIONS {
    . = 0xffffffff80100000;

    .text : ALIGN(4K) {
        *(.text._start)     /* put _start at the front */
        *(.text*)
    }

    .rodata : ALIGN(4K) {
        *(.rodata*)
    }

    .data : ALIGN(4K) {
        *(.data*)
    }

    .bss : ALIGN(4K) {
        __bss_start = .;
        *(.bss*)
        *(COMMON)
        . = ALIGN(8);
        __bss_end = .;
    }

    /DISCARD/ : {
        *(.eh_frame)
        *(.note*)
    }
}

What is going on here:

• ENTRY(_start) tells the linker which symbol is the program’s entry point.
• . = 0xffffffff80100000; sets the location counter to a virtual address up in the kernel half of the address space.
• Each SECTION_NAME : { ... } defines an output section. The *(.text*) pattern says “pull in every input section whose name starts with .text.”
• __bss_start = .; defines a symbol at the current location counter. It is not a variable; it is a name whose value is an address. The linker emits no bytes for it; it just records that the symbol __bss_start resolves to whatever value . had at that point.
• __bss_end = .; does the same after .bss is laid out.

Two things click into place when you understand this.

First, symbols and variables are different things. A C variable is an address that has storage. A linker symbol is an address that may or may not have storage. counter is a symbol whose address points to 4 bytes of writable storage. __bss_start is a symbol whose address is the start of .bss — there is no separate storage for __bss_start; the symbol’s value is the address.

This is why C code declares them as:

extern char __bss_start[];
extern char __bss_end[];

Not as extern char *__bss_start (which would be a pointer variable that itself has storage somewhere). The array notation says “this is a symbol whose address you can take.” Then __bss_start evaluates to the address itself, and you can write &__bss_start[0] or just __bss_start to get the start of the region.

Second, the linker script is what makes the C world and the hardware world agree on addresses. Without the linker script, the linker would have to guess. With it, you tell the linker: “I want .text at this address because that’s where the bootloader is going to drop me. I want .bss immediately after .data because contiguous layout makes the clear-loop easy. I want everything page-aligned because the MMU works on page granularity.”

The linker bakes those choices into the binary. Every mov [counter] instruction now contains the address counter would have if the binary were loaded as the script says. If you load it somewhere else, the addresses are wrong, and the CPU dutifully accesses the wrong memory.

(This is why position-independent code exists, but that’s a different essay.)

Worth dwelling on, because “uninitialized” sounds vague. The bytes have some value. What value?

It depends on a few things:

Power-on: DRAM cells settle into mostly-zero, mostly-random, or mostly-one states depending on the manufacturing process and the specific chips. Some patterns are stable (a particular cell tends to come up as 1); others are noise. Don’t rely on any pattern.

Warm reboot: DRAM keeps its contents through a warm reset because it’s continuously refreshed. So a warm reboot starts with whatever the previous OS left in RAM. If you booted Linux, used it for a while, then rebooted into your kernel, your .bss region might contain pieces of Linux’s kernel data, page cache, your browser’s memory, anything. This is a famous source of “works the first boot, fails on reboot” bugs.

ECC RAM: If ECC scrubbing is active, bits may be in a “consistent” state but still unpredictable.

Hypervisor-provided VM: Most hypervisors zero new VM memory before handing it to the guest. So .bss may coincidentally be zero on the first boot of a fresh VM, masking the bug entirely. Then you boot on real hardware and the kernel falls over.

Bootloader scratch: If the bootloader used some region for its own data structures, then loaded your kernel into a region that overlaps or is adjacent to where it scratched, your .bss may contain bootloader leftovers. Sometimes these have recognizable patterns (0xDEADBEEF, 0x55AA, etc.) which is a useful debugging hint.

The general truth: .bss memory before clearing contains arbitrary bytes that are not under your control. Anything that depends on those bytes being zero is broken.

Now the MMU enters and the picture gets harder, because the addresses in your binary are no longer the same as the addresses on the CPU’s address bus.

In a “higher-half” kernel, the linker script puts your kernel at a high virtual address, say 0xffffffff80100000. This means every instruction that references counter or __bss_start uses an address in that high range. The linker baked it in.

But when the CPU first starts executing your kernel, the MMU is either off or in a state where high virtual addresses don’t yet translate. The bootloader probably loaded the kernel’s bytes into low physical addresses, somewhere like 0x100000 (1 MiB). The CPU’s instruction pointer is at the physical address of _start, executing those low-physical-address bytes.

At this moment, if you tried to clear .bss using the virtual address from the linker:

for (char *p = __bss_start; p < __bss_end; p++) *p = 0;

then __bss_start evaluates to something like 0xffffffff80123000, and writing to that address either faults (no mapping) or modifies whatever low-physical address happens to be mapped at the identity-mapped portion of memory. Bad either way.

The mental fix is that before paging is set up, you have to talk to memory in physical addresses, not virtual. You can do this several ways:

1. Set up paging first — build page tables that map the kernel’s virtual addresses to its physical load addresses, enable the MMU, then jump to a virtual address and start using virtual addresses. After that, __bss_start evaluates to a real, mapped virtual address.

2. Clear .bss before paging, using physical addresses computed from the linker’s symbols. This requires some arithmetic: the linker can be told to expose __bss_start_phys as a different symbol equal to the physical address, or your early code can subtract a known offset (KERNEL_VIRT_BASE - KERNEL_PHYS_BASE) from __bss_start to get the physical address.

3. Have the bootloader clear it for you. If you used a multiboot ELF load, the bootloader walked the program headers and zeroed the .bss segment as part of loading. You don’t have to do it again.

Most kernels do option 1: set up paging early (often with a simple identity-mapped + higher-half mapping), then clear .bss using virtual addresses, because at that point the world looks the way the linker expected.

This is one of those situations where the linker confidently emits 0xffffffff80123000 as an address, and you, the human, have to ensure that the CPU’s view of memory matches the linker’s view before that address can be touched. The linker doesn’t enable the MMU. The CPU doesn’t know about the linker. The boot code is the diplomat.

Now we can finally appreciate the loop itself:

extern char __bss_start[];
extern char __bss_end[];

void clear_bss(void) {
    for (char *p = __bss_start; p < __bss_end; p++) {
        *p = 0;
    }
}

This works, but is byte-by-byte slow. In real kernels you’ll see something like:

void clear_bss(void) {
    uint64_t *p = (uint64_t *)__bss_start;
    uint64_t *end = (uint64_t *)__bss_end;
    while (p < end) *p++ = 0;
}

…provided the linker script aligns __bss_start and __bss_end to 8 bytes. (Hence the . = ALIGN(8); line in the linker script above.) Or:

memset(__bss_start, 0, __bss_end - __bss_start);

…provided memset itself doesn’t depend on any .bss state. That last condition is non-obvious. If memset is implemented in a way that touches a global, you have a bootstrapping problem: the function you’re using to make globals usable depends on globals being usable. Typical kernels either implement clear_bss in pure assembly, or implement memset very conservatively, or simply use the inline while loop above to avoid the question.

A more interesting question is whether the clear loop can use the CPU’s vector instructions (SSE/AVX/NEON) for speed. The answer in early boot is usually no — you may not have enabled the FPU/SSE state yet, and trying to execute an SSE instruction before that traps with #UD. So the early clear_bss is almost always plain integer code.

It’s also worth noting that you call clear_bss before kmain. It’s typically the second or third thing your C-callable startup function does, after setting up the stack and before calling anything that might rely on globals.

If you build the kernel as position-independent (PIC/PIE), the linker doesn’t bake in absolute addresses. Instead, every reference to counter or __bss_start is either PC-relative or goes through the Global Offset Table. The actual address is computed at load time based on where the loader places the image.

For .bss this changes nothing semantically: there’s still a region that must be zeroed, the symbols still point at it. But the addresses computed in the clear loop are now relative to the load address, so the loop works regardless of where the kernel was actually placed in physical memory.

Most kernels are not fully position-independent. They’re linked at a fixed virtual address and rely on the bootloader to place them at a corresponding physical address, then set up paging to map one to the other. Position independence introduces overhead and complexity that aren’t typically worth it for a monolithic kernel.

There’s a related concept called KASLR (kernel address space layout randomization) where the kernel is loaded at a random virtual address chosen at boot. This requires either full PIE or a small relocation step at boot that patches up absolute addresses. Either way, by the time .bss is cleared, the addresses in __bss_start and __bss_end have been resolved to their actual runtime values. The clear loop doesn’t know or care.

Walking up the stack of abstractions, one layer at a time:

1. The CPU sees a flat physical address space (modulo MMU) and an instruction pointer. It has no idea what a section is, what a symbol is, or what zero-initialization means. It just reads and writes addresses.

2. The C language sees a flat byte-addressable virtual memory and a contract: variables with static storage duration and no initializer start at zero. This contract is the C abstract machine’s promise to the programmer.

3. The compiler translates C source into bytes plus metadata. Variables with explicit non-zero initializers become bytes in .data plus a symbol table entry. Variables without initializers become a size in .bss plus a symbol table entry (no bytes). Functions become bytes in .text plus a symbol table entry.

4. The linker combines object files. It concatenates same-named sections, picks final addresses based on the linker script, resolves all symbol references, and emits an executable. For .bss, it records the size and address but emits no bytes. It also emits sentinels like __bss_start and __bss_end for the runtime’s use.

5. The file format (ELF) encodes the result. Sections are the linker’s view. Segments (program headers) are the loader’s view. A LOAD segment with p_filesz < p_memsz says “load p_filesz bytes from the file and zero-fill p_memsz - p_filesz more.”

6. The loader (in a hosted environment, the OS kernel’s ELF loader) walks the program headers, maps file-backed memory for p_filesz, maps anonymous (zero-filled) memory for p_memsz - p_filesz, and jumps to the entry point. The C abstract machine’s contract is now satisfied for static storage.

7. The runtime (crt1.o, libc) sets up the stack frame, runs .init_array, calls main. User code executes inside a world where the contract is fully real.

In a freestanding kernel, layers 6 and 7 collapse into your boot code. You are the loader. You are the runtime. You set up paging, you clear .bss, you call kmain. The line of assembly that says “set %rdi to __bss_start, set %rcx to __bss_end - __bss_start, rep stosb” is the moment you fulfill the contract on behalf of every int x; in your kernel.

That’s what clearing .bss is. Not a ritual, not a quirk, not historical baggage. It’s the single explicit step that makes the C language’s promises real on hardware that has no opinion about them. The CPU doesn’t care. The linker assumed you’d handle it. The bootloader may or may not have. The C code is going to depend on it. So you write the loop, and the abstraction stack stops bleeding.