Frank DENIS random thoughts.

Branches in branch-free code

2026-10-09T00:00:00+02:00

Let’s add two numbers

Here’s a complete C function that adds two unsigned 128-bit integers:

typedef unsigned _BitInt(128) u128;

u128 add(u128 a, u128 b) {
    return a + b;
}

Now let’s compile it for 32-bit RISC-V:

clang --target=riscv32 -march=rv32imac -mabi=ilp32 -O2 -S add.c -o -

You can see the output on Compiler Explorer, alongside versions compiled with GCC and with the Zicond extension we’ll look at below.

Here’s the relevant snippet:

        add     a1, t1, t0
        add     a2, a7, t2
        sltu    t0, a1, t1
        add     a2, a2, t0
        beq     a2, a7, .LBB0_2
        sltu    t0, a2, a7
.LBB0_2:
        add     a5, a5, a3
        add     a4, a4, a6
        add     t0, t0, a5
        sltu    a3, a5, a3
        sltu    a5, t0, a5

Wait, why is there a beq in an addition? That’s a conditional branch, right?

RV32 registers hold 32 bits, so LLVM has to split our 128-bit addition into four smaller ones, passing the carry from each to the next.

This is how the compiled code performs the addition; a0 and b0 are the lowest 32-bit words of our inputs; a1 and b1 are the next ones. All values are unsigned, low32() keeps only the lowest 32 bits, and comparisons return 0 or 1.

sum0 = low32(a0 + b0)
carry0 = (sum0 < a0)

sum1 = low32(a1 + b1 + carry0)

if sum1 == b1:
    carry1 = carry0
else:
    carry1 = (sum1 < b1)

Can you guess why sum1 == b1 is checked?

CPUs such as x86 and AArch64 have instructions to perform conditional moves (cmov), allowing carry propagation to be implemented without a branch.

But on RV32, even comparing two 64-bit integers with < produces a branch.

What about the usual bit mask?

We’ve been talking about carry propagation in large integers, but if you’ve written constant-time code, you’ve probably used some version of this everywhere:

#include <stdint.h>

uint32_t ct_select(uint32_t bit, uint32_t a, uint32_t b) {
    uint32_t mask = -(bit & 1);
    return (a & mask) | (b & ~mask);
}

If the low bit of bit is set, mask is all ones, so the expression keeps a and zeros out b. Otherwise, the mask is zero and we get b.

Just bitwise operations, no branch in the source.

Let’s compile that for RV32 with clang 23:

ct_select:
        andi    a0, a0, 1
        beqz    a0, .LBB0_2
        mv      a2, a1
.LBB0_2:
        mv      a0, a2
        ret

Aaaahhhhhhhh, a beqz instruction, branching on the bit we just masked. So much for carefully writing the selection with bitwise operations.

And this also happens on 64-bit RISC-V.

You can see the compiled code on Compiler Explorer which includes both targets, plus clang 17, GCC and Zicond for comparison.

Why include clang 17? Because the branch was there in 15, gone in 16 and 17, and back from 18 to 23. Fun, uh?

So, even if you reviewed assembly code with a given version of the compiler, and everything looked fine, every change to the compiler version of compiler flags requires a new review.

What about Zig?

Let’s try the 128-bit addition in Zig, along with the same bit-mask selection:

export fn add(a: *const u128, b: *const u128, r: *u128) void {
    r.* = a.* +% b.*;
}

export fn ctSelect(bit: u32, a: u32, b: u32) u32 {
    const mask = 0 -% (bit & 1);
    return (a & mask) | (b & ~mask);
}

zig build-obj add.zig -target riscv32-freestanding -O ReleaseFast -femit-asm=add.s -fno-emit-bin

Same beq after the second word, and the selection gets the same beqz (Compiler Explorer code).

Changing the source language doesn’t get us out of this. And yes, Rust has the same issue.

What about other platforms?

Now let’s compile C examples for a few other targets.

I also added a 64-bit a < b comparison, since that was enough to produce a branch on RV32.

These are the numbers of conditional branches and conditional returns emitted by clang 23 at -O2.

As usual everything can be verified on Compiler Explorer:

Target	`add`	`ct_select`	64-bit `<`
x86_64, x86	0	0	0
AArch64, 32-bit ARM, Cortex-M3	0	0	0
MIPS32, LoongArch64, WebAssembly	0	0	0
Cortex-M0	0	1	1
32-bit PowerPC	0	1	2
RV32	1	1	1
RV64	0	1	0
RV32 and RV64 with Zicond	0	0	0

Targets with zeros are safe. Everything else has ugly side channels in spite of source code looking like it runs in constant time.

WebAssembly has a select (cmov) instruction, so no obvious conditional jumps are visible in the modules, but then WebAssembly compilers can do whatever they want. On platforms without equivalent native instructions, it’s likely that we’ll get a jump.

Cortex-M0 (Thumb-1) and generic 32-bit PowerPC don’t have an cmov-like instructions, so they branch.

Let’s try GCC

Now here’s a pleasant surprise: GCC 16.1 compiles both examples without branches on RISC-V. Its carries use sltu, and it leaves the mask arithmetic alone.

Cool. But let’s make a small change: derive the mask from a comparison.

uint32_t m = -(uint32_t) (x < y);
return (a & m) | (b & ~m);

And… the branch is back!

GCC now emits a bgeu on both RV32 and RV64 (Compiler Explorer). It also branches on 64-bit comparisons on RV32.

Can we hide the mask from the optimizer?

For the bit-mask example, there’s a common workaround: pass the mask through an empty asm statement before using it. Let’s do that:

uint32_t ct_select(uint32_t bit, uint32_t a, uint32_t b) {
    uint32_t mask = -(bit & 1);
    __asm__("" : "+r"(mask));
    return (a & mask) | (b & ~mask);
}

The assembly does nothing, but its declaration tells the compiler that it may change mask.

Now, both versions compile without branches on RV32 and RV64. Phew.

Can we do the same for the addition?

I tried hiding the inputs behind a memory barrier, and the branch stayed. But putting a register barrier on each of their 32-bit words worked, and every carry became an sltu.

Both attempts are on Compiler Explorer.

To be honest, I wouldn’t rely on either barrier experiment as a fix for the addition.

For arithmetic involving secrets, I’d avoid integer types wider than two registers and write the carries explicitly, using 32-bit words on RV32.

Currently, clang 23 keeps my hand-written carry chain free of branches, but who knows what will happen in the next releases.

Giving LLVM the missing instructions

For RISC-V, there’s a solution, though: RISC-V has an extension called Zicond.

It adds czero.eqz and czero.nez, which zero a register depending on whether another register is zero. And that can be used to select a value without branching.

Let’s enable it with -march=rv32imac_zicond and compile our bit-mask example again:

ct_select:
        andi       a0, a0, 1
        czero.eqz  a1, a1, a0
        czero.nez  a0, a2, a0
        or         a0, a0, a1
        ret

Yay, no jumps. Every case tested above is free of branches with Zicond enabled.

Zicond is part of the RVA23 profile, but unfortunately many cores in use today don’t implement it, especially microcontrollers.

And even if it’s available, there’s an important detail that’s easy to overlook: the Zicond specification only guarantees that their timing is independent of the data if the Zkt extension is also implemented.

Writing secure, portable code is hard. Protecting against side-channels is as footgunish as zeroing secrets.

Oh, and if you haven’t read it yet, Thomas Pornin’s Why constant-time crypto? and Constant-time multiplication pages are absolutely worth a read.

Zeroization, part 3: Copies you can’t wipe

2026-10-06T00:00:00+02:00

Welcome to part 3 on zeroization! We added a wipe in part 1 and created an extra copy. And in part 2, we looked at some options to clear the stack and registers.

But why did we need some of those copies in the first place? Turns out that sometimes the answer is right there in the API.

Do we need that buffer?

Let’s go back to the textbook example: MAC verification.

We initialize the state of a MAC function (could be HMAC, an AEAD, etc.), update the state with a message to authenticate, finalize the state, compute the expected tag, compare it with the received tag, and return whether they match.

In the toy example below, the state is just two 128-bit blocks, and to produce a tag, we just XOR them to produce a 128-bit tag.

#include <stddef.h>
#include <stdint.h>

typedef struct {
    uint8_t a[16];
    uint8_t b[16];
} final_state;

__attribute__((noinline))
void extract_tag(const final_state *state, uint8_t out[16])
{
    for (size_t i = 0; i < 16; i++) {
        out[i] = state->a[i] ^ state->b[i];
    }
}

static int ct_verify16(const uint8_t a[16], const uint8_t b[16])
{
    unsigned int different = 0;
    for (size_t i = 0; i < 16; i++) {
        different |= a[i] ^ b[i];
    }
    return different == 0;
}

int verify_tag(const final_state *state, const uint8_t candidate[16])
{
    uint8_t expected[16];

    extract_tag(state, expected);
    return ct_verify16(expected, candidate);
}

The noinline attribute deliberately prevents the extraction from being inlined, which is what a compiler would do in a real implementation if the extraction code is in a substantial finalization function.

Look at expected.

Even if extract_tag() computes the tag entirely in registers, its interface requires it to write those bytes through an output pointer. And the caller has to provide storage for them.

We could wipe that storage afterward, but we’d still have required it to exist.

Let’s do something else, then: fuse the computation and the check of the tag in the same function:

int verify_fused(const final_state *state,
                 const uint8_t candidate[16])
{
    unsigned int different = 0;
    for (size_t i = 0; i < 16; i++) {
        different |= state->a[i] ^ state->b[i] ^ candidate[i];
    }
    return different == 0;
}

There’s no output pointer for an intermediate tag here. Each extracted byte goes straight into the comparison, and the only result is a boolean.

The state may still be sensitive information, but the expected tag is not present in stack memory. There’s no hard promise that a compiler wouldn’t spill a temporary, but it is very unlikely as it would make absolutely no sense from a performance perspective.

So, simply combining finalization and verification can help mitigate leakage.

The same reasoning applies to passing small keys by pointer. If an out-of-line callee needs an address, the caller may have to store a value it already has in a register.

Passing by value can avoid that on a suitable ABI, even though there’s still no hard guarantee that the callee won’t spill it.

So don’t pick the pointer version merely because it looks easier to wipe. Check the generated code and decide who owns the value and when they’re done with it.

Can the comparison erase the tag?

Here’s another tempting idea.

We already XOR the tags to compare them, so why not overwrite the computed tag as we compare it with the candidate?

unsigned int different = 0;
for (size_t i = 0; i < length; i++) {
    computed[i] ^= candidate[i];
    different |= computed[i];
    computed[i] = 0;
}
return different == 0;

Did that erase the computed tag?

Looking at the source code, it should. But compilers are sneaky and in a all the tests I ran, I got exactly the same instructions as a normal XOR/OR equality reduction.

So, don’t try to be creative. Keep tag extraction close to that comparison where it avoids unnecessary storage, and inspect whether the compiler actually kept them together.

WebAssembly makes this worse

In native code, the boundary we described in part 2 could clear the registers and stack region used by an operation.

But WebAssembly is a different beast. WebAssembly code doesn’t control the machine registers or the engine’s native stack. The engine decides how its values are represented there.

To the VM, a key is just an i64, a v128, or some bytes in memory.

And WebAssembly doesn’t define any ways to tell the engine to track sensitive copies and erase them. A key gets the same treatment as any other value of its type. Proposals to improve that situation have been ignored and eventually abandoned.

In a JIT-based VM, that leaves another optimizer free to introduce copies, spill values, move calculations across a wipe, or discard an unused assignment of zero. The VM only cares about observable behavior.

The application neither chooses those copies’ locations nor gets a way to clear them.

WebAssembly itself is useless without external, imported functions provided by the runtime. Think about them like syscalls in a native environment.

A WebAssembly application passing a secret to an external function implemented by the runtime has no control over it. The runtime can make as many copies as needed, and from within the WebAssembly sandbox, none of these copies is accessible and can be cleared.

Clearing a Wasm local doesn’t clear a register

Inspecting a WebAssembly module is not enough to predict whether secrets will be cleared, even if the disassembly of the module says so.

Here’s an example of a module that XORs an input with a constant, uses that intermediate in a calculation, then assigns zero to $intermediate:

(module
  (func (export "local_clear") (param $input i64) (result i64)
    (local $intermediate i64)
    (local $result i64)
    local.get $input
    i64.const 0x9e3779b97f4a7c15
    i64.xor
    local.tee $intermediate
    i64.const 17
    i64.shr_u
    local.get $intermediate
    i64.const 0xd6e8feb86659fd93
    i64.mul
    i64.xor
    local.set $result
    i64.const 0
    local.set $intermediate
    local.get $result))

We were able to defeat the C/Rust/Zig and LLVM optimizations, and we got a local.set $intermediate that replaces the secret with 0. Perfect!

But here comes the second compiler, the one that will compile the WebAssembly code to native code so it can actually run.

I tested this with Wasmtime and Wasmer, using Cranelift and LLVM: both produced identical native function bodies with and without the local clear.

Let’s look at the relevant Wasmer output, with constant loads omitted:

eor     x8, x1, x8
mul     x9, x8, x9
eor     x0, x9, x8, lsr #17
ret

x8 contains the secret. It’s not cleared, in spite of all our efforts and what the WebAssembly bytecode says.

The wipe can create a native spill too

Let’s see another example:

__attribute__((noinline))
int check_and_wipe(const uint8_t seed[16],
                   const uint8_t candidate[16])
{
    uint8_t expected[16];
    for (size_t i = 0; i < 16; i++) {
        expected[i] = seed[i] ^ 0x5a;
    }
    int same = ct_verify16(expected, candidate);
    secure_zero(expected, sizeof expected);
    return same;
}

The source compares first, then wipes.

But compiling this with LLVM 23 shows that the compiled Wasm keeps the computed tag and candidate in locals, calls the wipe, and only then finishes the comparison.

This is an acceptable thing to do for a compiler: it doesn’t change the function’s result or the bytes the wipe writes.

But what does the engine do with those locals across the call?

With Wasmtime, this is what I saw (relevant instructions only):

str     q20, [x0, w4, uxtw]
stur    q20, [sp, #0x10]
bl      #0x380
ldur    q20, [sp, #0x10]

x0 is the base of linear memory and w4 is the expected offset within it.

The first store writes the computed tag there. The second writes the same tag to the engine’s native stack.

The call at 0x380 clears the linear-memory object, and the final load brings back the untouched native copy for comparison.

The complete function returns without clearing that spill slot.

expected is cleared, but the engine still has another copy, at an address the module can’t wipe.

Even a module without memory uses memory

Let’s remove linear memory completely. No C stack, no buffers, no imports, and no load or store instructions. This complete module just computes x XOR (4 * (x + 1)), with arithmetic modulo 2^64:

(module
  (func $triple (param $x i64) (result i64)
    local.get $x
    i64.const 3
    i64.mul)
  (func $combine (param $x i64) (result i64)
    local.get $x
    local.get $x
    call $triple
    i64.add)
  (func $across (export "across") (param $x i64) (result i64)
    local.get $x
    local.get $x
    i64.const 1
    i64.add
    call $combine
    i64.xor))

If x were sensitive, where would it go?

Let’s try with Cranelift: across() keeps its original input in x19 while calling combine(). But combine() also wants to use x19, so it saves the caller’s value on the native stack:

str     x19, [sp, #-0x10]!
mov     x19, x4
bl      #0
add     x2, x19, x2
ldr     x19, [sp], #0x10

Here, bl #0 calls triple(). The final load restores x19, but leaves the input on the native stack after both functions return.

The wasm module can’t do anything to wipe it.

A note on “volatile”

The volatile attribute is understood by source-to-wasm compilers and can keep a buffer wipe in the generated WebAssembly module.

But the volatile attribute doesn’t exist in the specification; from a WebAssembly runtime perspective, clearing memory with or without volatile makes no difference: the code is exactly the same, so it will be optimized out the same way.

By the way, in WebAssembly, memory barriers don’t do anything either. So don’t expect them to mitigate speculative execution or help mitigate side channels.

So what can we do?

Zeroing memory using compiled languages and/or virtual machines is pretty much impossible to do correctly.

My recommendations for library authors:

Inspect the generated code. This is the source of truth, not the source code.
Wipe secrets that will almost certainly be stored in memory, such as passwords, hex/base64-encoded keys, etc.
Always wipe secrets present on the heap
Use protected memory when possible. For example, the libsodium guarded memory functions are quite useful. If only to find bugs in implementations.
For everything else, small values that are actually used to perform computations, don’t bother.

My recommendations for library users:

Use encrypted swap and encrypted filesystems, and configure your OS and hardware correctly.
Apply the recommendations from part 2 if you’re really worried about dangling secrets in memory and registers. Write libraries like zig-secretstack for your favorite programming language that are easy to use.

Zeroization, part 2: Clearing the stack and registers

2026-10-06T00:00:00+02:00

In part 1, we saw that code intended to wipe secrets can end up creating extra copies.

So what can we do?

The best mitigation is to use a compiler designed to natively address that issue.

Jasmin is a perfect example of this. Jasmin is a high-level assembler, similar to Dan Bernstein’s qhasm, that makes writing assembly code very pleasant, if only because it can do automatic register allocation.

But Jasmin does a little bit more: the compiler is able to prove that values tagged as secrets are never returned as public values, are not involved in operations that wouldn’t run in constant time, and are safe against some classes of SPECTRE attacks. And for code using pointers, it’s even able to prove memory safety.

In addition to that, and this is where things become relevant to our topic, Jasmin can automatically wipe all the values tagged as secret before returning from a function, regardless of where they live (registers or stack memory).

Jasmin is an awesome tool for generating high-performance, high-assurance code.

And for a real-world example of Jasmin source code, check out the Jasmin implementations of AEGIS, which are also the fastest implementations of AEGIS to date.

Unfortunately, writing everything in Jasmin is not always practical, so we have to find mitigations for common compiled languages.

Decide where the operation ends

Instead of trying to solve the problem at the microscopic level, we can take a higher-level approach: find clear boundaries within which secrets are used, but beyond which they’re no longer used.

Suppose our application derives an ephemeral key, processes a batch of records, and then discards the key. We can put that whole sequence inside one boundary:

enter boundary (function)
    derive ephemeral key
    process records
    retire owned key and context buffers
leave boundary
    clear stack used by the work and its callees
    clear residual registers
return status

Notice where the key derivation happens: inside the boundary.

For practical purposes, a boundary will be a function, so if we derive the ephemeral key in the caller first, we may already have copies in that caller’s frame or preserved registers.

Let’s ask the compiler

GCC and Clang have little-known compilation flags to automatically clear registers before a function returns:

clang -O3 -fzero-call-used-regs=all -c crypto.c

The flag applies to the compilation unit, but with the zero_call_used_regs("all") attribute, we can apply this selectively to relevant functions instead:

struct request;

__attribute__((noinline, zero_call_used_regs("all")))
int secret_batch(struct request *request);

Now look at the end of the leaky example from part 1, compiled with that feature enabled. After calculating the return value, we get these instructions among the added overwrites:

mov     x8, #0
mov     x9, #0
movi.2d v0, #0000000000000000
movi.2d v1, #0000000000000000

There we go. x8 actually gets cleared this time. And the result in x0 survives, as it should.

This Godbolt comparison shows the same source with and without register cleanup.

This is a great improvement, but it’s not enough. It doesn’t discover spills in callees, and a spotless wrapper epilogue can leave a key schedule below it on the stack.

Now let’s ask GCC to handle the stack as well:

gcc -O2 -fstrub=all -fzero-call-used-regs=all -c crypto.c

Its strub mechanism tracks stack use with a watermark, then clears the recorded region after the call. GCC documents those interfaces here.

The strub contract is also a useful read.

What about our own register-wiping helper?

We saw compiler-specific flags. But why not write our own implementations in portable C, maybe just with a bit of assembly? Writing a few zeroing instructions sounds easy enough.

Unfortunately, there’s a trap: ABIs. Calling conventions that typically require functions to preserve a set of registers.

As an illustration, let’s look at what happens when an ordinary function tries to clear a register it must preserve for its caller. Here’s an abbreviated AArch64 sequence:

str     x19, [sp, #-16]!
mov     x19, #0
ldr     x19, [sp], #16
ret

There’s our mov x19, #0. Code we presumably explicitly added to clear the x19 register containing a secret. And right after it… ldr restores the old value.

Oops! The helper has undone its own wipe :)

The caller gets its register back, as the ABI requires, and the temporary stack save is still in memory too.

So, a wipe_registers() helper (which itself is trickier to write than it appears, especially for software supposed to be portable) can’t freely destroy all registers and remain an ordinary ABI-compliant call.

And putting the registers in an inline assembly clobber list doesn’t get us out of this either. It would just tell the compiler to protect live values, which can mean making more copies.

A boundary wrapper instead preserves the caller’s original state, runs the secret work, clears that work’s stack, and clears the residual register state it may discard.

What about our own stack-wiping helper?

How much stack should we wipe when leaving a boundary?

This is not easy to answer: adding up our local arrays isn’t enough. We need to include callees, compiler spills, alignment, saved registers, and ABI areas such as the x86_64 red zone. Yay.

We could measure how deep one call goes, but recursion, variable-sized frames, callbacks, and instrumentation can change it.

Compilers have flags that can help track the stack usage of functions, but in practice, this is a mess of hard-coded, hard-to-maintain, unreliable limits that may become invalid as soon as a single change is made to the code or compiler.

Giving the work its own stack

A different approach: let’s give an operation involving secrets a dedicated stack. We can run the sensitive sequence there, switch back, and clear the whole allocation.

We allocate the region, so we know where it starts and where it ends. We know that wiping the entire region is going to wipe everything stored on the stack inside the boundary.

Plus, the region can be surrounded by guard pages, marked for exclusion from swap and core dumps, etc. Keeping the stack that holds secrets in a different (and randomized) memory location than the regular application stack also makes a whole class of attacks more difficult.

I wrote C and Zig (secretstack) implementations. For reference, the C implementation has a simple entry point that looks like this:

long secure_call_on_stack(long (*fn)(void *), void *ctx,
                          void *stack, size_t stack_len);

The callback returns a status and receives its inputs through ctx. And this is what the wrapper does after the callback returns:

    mov     sp, x21
    mov     x9, x19
    b       2f
1:  stp     xzr, xzr, [x9], #16
2:  cmp     x9, x20
    b.lo    1b

x21 holds the wrapper’s original stack pointer. We’re switching back before overwriting the dedicated stack. Then the dedicated stack gets wiped: x19 holds the start of the region and x20 its end.

The beauty of this approach is that it works with virtually anything. Any existing library. Even if that library didn’t itself try to wipe the secrets it receives or creates, we end up with zero copies of these secrets in memory after the function returns.

Clear the registers in addition to this, and you’re in pretty good shape.

Unfortunately, there’s more to switching stacks than changing sp. Unwinding, sanitizers, profilers, and language runtimes may keep their own stack bookkeeping, so integration can be tricky.

Either support exceptions, cancellation, and nonlocal exits through boundaries, or (way easier) prohibit them and enforce normal callback return.

And of course, ban longjmp.

Another issue is that if a signal interrupts the work, its saved register context may land on a signal stack outside the region we’re about to erase, because sigaltstack() uses a signal-handler stack.

So, one has to remain careful about what runs inside a boundary. But these constraints can usually be easily satisfied for cryptographic code.

Overhead

Of course, clearing entire regions and tons of registers has a cost.

If the boundary only encrypts or hashes a short input, it’s likely that clearing registers and a dedicated stack can take longer than the operation itself.

However, doing it once after a handshake or a batch that shares the same secret lifetime is likely to have a negligible cost.

As always in security, everything is about tradeoffs.

See you in part 3.

Zeroization, part 1: Wiping can make things worse

2026-10-06T00:00:00+02:00

A good hygiene when processing secrets is to wipe them after use.

And projects receives countless PRs about adding calls to zeroization functions for anything that looks like a secret.

This is a low-hanging fruit, something LLMs love to report, and it feels theoretically useful. But unfortunately, things are a little bit more complicated. Blindly zeroing secrets can do more harm than good.

Turns out that adding a wipe for a secret can leave more copies of a secret than the original code. Copies that wouldn’t have existed without it, and that are still there after it returns.

Code snippets and their compiled output can be verified in this Godbolt example.

Let’s start with memset()

Classic starting point: the good old memset() call that gets optimized out:

We calculate an intermediate value, use it to produce a result, then clear it before returning.

#include <stdint.h>
#include <string.h>

uint64_t ordinary_memset(uint64_t input)
{
    uint64_t intermediate = input ^ UINT64_C(0x9e3779b97f4a7c15);
    uint64_t result = (intermediate >> 17) ^
                      (intermediate * UINT64_C(0xd6e8feb86659fd93));
    memset(&intermediate, 0, sizeof intermediate);
    return result;
}

Now remove the memset() and compare the generated instructions. They are identical.

The compiler was smart enough to understand that wiping intermediate is a useless operation since after the function returns, it’s never read again.

But before we try to fix this, notice something else in the assembly output: the intermediate never went into memory at all. It stayed in registers.

Let’s make the stores survive

The most common practice to address the issue: replacing the memset() with volatile byte stores:

volatile unsigned char *bytes =
    (volatile unsigned char *)&intermediate;
for (size_t i = 0; i < sizeof intermediate; i++) {
    bytes[i] = 0;
}

Let’s do it and observe the arm64 output (I used XCode, shipping Clang 21):

eor     x8, x0, x8
strb    wzr, [sp, #8]
strb    wzr, [sp, #7]
strb    wzr, [sp, #6]
strb    wzr, [sp, #5]
strb    wzr, [sp, #4]
strb    wzr, [sp, #3]
strb    wzr, [sp, #2]
strb    wzr, [sp, #1]

Eight strb instructions. wzr supplies zero.

Perfect, we defeated the compiler’s optimization passes and actually wrote eight zero bytes to stack memory!

Wait… where’s the instruction that put our intermediate into those stack slots?

Surprise: there isn’t one.

x8 holds the intermediate. We’ve just written eight zero bytes to locations that never received the value we wanted to erase.

The function then calculates the result from x8 and returns without clearing it.

The actual secret value is still around and we just wasted CPU cycles for nothing.

What if we hide the wipe from the compiler?

Let’s try another common approach: put the wiping code in a dedicated function, in a separately compiled file, without LTO.

You know, some variant of a secure_zero() function that can be found everywhere in cryptographic libraries:

#include <stddef.h>

void opaque_wipe(void *pointer, size_t length)
{
    volatile unsigned char *bytes = pointer;
    while (length != 0) {
        *bytes++ = 0;
        length--;
    }
}

The caller only sees the declaration, so it can’t inspect the implementation when compiling this call:

opaque_wipe(&intermediate, sizeof intermediate);

Cool, so let’s look at the caller’s assembly output now.

Intestering: there’s a new instruction before the call:

str     x8, [sp, #8]

Duh? We’re storing the intermediate on the stack now? The original function didn’t do that!

Yep, the wipe needs an address. And since the caller can’t see the implementation, it has to allow for the callee reading the old contents at that address. So it writes the value there first.

The wipe clears that new stack copy and leaves x8 alone.

We’ve introduced an interval during which the value exists in memory, paid to clear it, and still kept the register copy.

Also, a recognized write-only operation can skip this particular store, and if LTO is enabled (quite the norm these days), our attempt to hide the implementation in another file is likely to become useless.

Now let’s compare a tag

Now let’s do something very common but a little less trivial: compute a tag (HMAC output, etc.), compare it, wipe it, return the result.

In this example, we’re going to compute the tag as seed[i] ^ 0x5a. This is completely dumb and insecure, but easy to follow through the assembly.

We want to securely compare it against an application-provided tag.

#include <stddef.h>

void opaque_wipe(void *pointer, size_t length);

int compare_and_wipe(const unsigned char seed[16],
                     const unsigned char candidate[16])
{
    unsigned char computed[16];
    for (size_t i = 0; i < 16; i++) {
        computed[i] = seed[i] ^ 0x5a;
    }

    unsigned int different = 0;
    for (size_t i = 0; i < 16; i++) {
        different |= (unsigned int)(computed[i] ^ candidate[i]);
    }
    int equal = different == 0;
    opaque_wipe(computed, 16);
    return equal;
}

Compile the caller and wipe separately, without LTO:

clang -std=c11 -O3 -Wall -Wextra -Werror -S compare.c -o compare.s
clang -std=c11 -O3 -Wall -Wextra -Werror -c wipe.c -o wipe.o

In the C code, the comparison appears before the wipe.

But let’s take a closer look at the disassembled output.

sub     sp, sp, #80
stp     x29, x30, [sp, #64]
add     x29, sp, #64
ldr     q0, [x0]
movi.16b v1, #90
eor.16b v0, v0, v1
str     q0, [sp, #16]
stur    q0, [x29, #-24]
ldr     q0, [x1]
str     q0, [sp]
sub     x0, x29, #24
mov     w1, #16
bl      _opaque_wipe
ldp     q1, q0, [sp]
cmeq.16b v0, v1, v0

Wait. Why are there two stores of q0 after the XOR?

And why is the comparison instruction, cmeq, after the call to the wipe?

To understand, let’s map the stack. We’re going to call the stack pointer after allocating the frame S; the frame pointer, x29, is S + 64.

Stack bytes	Contents	Wiped?
`S` through `S + 15`	Candidate	No
`S + 16` through `S + 31`	Extra computed-tag copy	No
`S + 40` through `S + 55`	Addressed `computed` object	Yes

Ah! The compiler loaded the comparison operands before the call, but postponed the comparison itself until afterward.

To keep the computed tag available across the call, it made a second copy in a spill slot.

Our wipe clears the requested 16 bytes perfectly, no problem here. And then ldp reloads the other copy, and cmeq compares it.

But nothing clears that spill slot before the function returns!

Now the fun part: what if we remove the wipe and compile again?

Surprise: the computed tag no longer gets stored on the stack at all. Everything stays in registers.

Adding the wipe created the copy we left behind.

Note that there’s no compiler bug here. The return value is correct, the addressed object is overwritten, and C doesn’t promise the security ordering you intended between those two events.

You can compare both functions in Godbolt.

There, the addressed object is at sp + 32 rather than sp + 40 (which I got with Xcode), but the extra copy at sp + 16 still survives the wipe.

Disabling stack protection generates different code, but this is more of an accidental unreliable side effect than a fix or a good idea.

So we’re sometimes paying for stores, and sometimes for a new call and stack copy, and the secrets are still around. Pretty frustrating for a change that was supposed to improve cleanup.

Registers shouldn’t be ignored

Registers are copied to memory after every context switch. Registers are visible in core dumps, hibernation files and VM snapshots. Registers can leak through microarchitectural bugs (Zenbleed).

And a single SIMD register can hold an entire 256-bit secret key, or even a 512-bit hash. They also tend to be recycled less frequently than general-purpose registers. But traditional zeroing functions are just designed to write zeros to memory, and have no clue about actual execution flows.

Keep the useful wipes

Does this mean we should stop wiping password buffers? No: those buffers already exist in memory, and clearing them when we’re done is useful. The same goes for an allocated key schedule or a context we’re retiring.

But in the examples above, the values we cared about were also somewhere else.

So before adding a wipe to a small local, inspect whether the value already lives in memory, whether taking its address creates storage, and what stays live across the call. Check the optimized build you ship, including LTO and hardening flags.

Or stop blindly sprinkling calls to buffer wiping functions. There are more reliable techniques to wipe secrets.

We’ll see that in part 2.

Do your employees actually use your product?

2026-09-25T00:00:00+02:00

I’m old, and I’ve worked with a lot of companies, large and small. Some employed me, while others were clients.

The most innovative and productive companies I’ve worked with had something in common: employees used the company’s products because they wanted to.

When I worked on Skyblog, Skyrock’s French blogging platform, everybody there used the product. And I really mean it: everybody. Night and day. And we had a lot of fun with it.

So we cared a lot about it as both employees and as users.

Skyblog is gone now, but my former colleagues and I still have great memories of working on it, even though we worked like crazy.

That willingness to use the product tells me more about a company than the size of its budget.

A company can hire excellent people and have a convincing plan for the future. But neither guarantees that anyone there will choose the product when they have a choice.

That’s why I like seeing employees use their company’s product for their own projects outside work. They might even be paying for it.

Using it at work can mean nothing more than testing a feature or preparing a demo for a customer. But that doesn’t tell you whether someone would choose it for themselves.

When you’re trying to do something for yourself, the product’s limitations become your problem too, so you want them fixed.

Knowing how the code works won’t spare you the annoyance of a bug that gets in your way. And once you’ve had to live with that bug, you understand the complaint a lot better than you did while reading its description.

In my experience, people who enjoy using a product already have a reason to want it improved.

They get something out of the work themselves. That sort of attachment is hard to create through pressure or a company culture program.

It also gives people ideas about what to build next: as they keep using the product, they notice what’s missing and start thinking about how they’d like it to work. So they can suggest something useful before a customer has had to ask for it.

A product manager can know the market very well and still get something out of using the product every day. Developers can too.

Building a feature and relying on it for your own project give you different experiences, and I’ve learned to be careful about assuming one gives you the other.

For that to work, employees who report a problem need the same attention as other customers.

They should be able to get an answer without having to chase several teams. If a report from an employee is harder to get addressed than the same report sent through customer support, something needs fixing in that process.

And people who enjoy using a product recommend it to others. They can explain why it’s useful because they’ve relied on it themselves.

That can benefit the company years later, when a former employee recommends the product to colleagues at another job.

Their new company may become a customer because someone there knows how to get useful work done with it. Having worked on the code alone doesn’t give someone the same experience to draw on.

Customer requests are useful, but if every change starts with a request from a customer or a potential customer, the company is always waiting for somebody else to identify the next thing to do.

Employees who use the product can bring ideas of their own.

So when I think about what helps a company come up with useful improvements, one of the first things I’d look at is whether its employees choose to use what they’re building.