Terminology#

In the following assembly rewrites, some shorthand is used.

• xN or wN: refers to any general-purpose non-reserved register.

• {a,b,c}: matches any of a, b, or c.

• LDSTr: a load/store instruction that supports register-register addressing modes, with one source/destination register.

• LDSTx: a load/store instruction not matched by LDSTr. This covers load/store pairs (ldp/stp), SIMD load/stores (ld1, st1, …), atomics, exclusives, load/store-release, and unscaled (ldur/stur) forms. These instructions have a more limited set of addressing modes than LDSTr.

Control flow#

Indirect branches get rewritten to branch through register x28, which must always contain an address within the sandbox. An add is used to safely update x28 with the destination address. Since ret uses x30 by default, which already must contain an address within the sandbox, it does not require any rewrite.

{br,blr,ret} xN

add x28, x27, wN, uxtw
{br,blr,ret} x28

ret

ret

Memory accesses#

Memory accesses are rewritten to use the [x27, wM, uxtw] addressing mode if it is available, which is automatically safe. Otherwise, rewrites fall back to using x28 along with an instruction to safely load it with the target address.

LDSTr xN, [xM]

LDSTr xN, [x27, wM, uxtw]

LDSTr xN, [xM, #I]

add x28, x27, wM, uxtw
LDSTr xN, [x28, #I]

LDSTr xN, [xM, #I]!

add xM, xM, #I
LDSTr xN, [x27, wM, uxtw]

LDSTr xN, [xM], #I

LDSTr xN, [x27, wM, uxtw]
add xM, xM, #I

LDSTr xN, [xM1, xM2]

add x26, xM1, xM2
LDSTr xN, [x27, w26, uxtw]

LDSTr xN, [xM1, xM2, MOD #I]

add x26, xM1, xM2, MOD #I
LDSTr xN, [x27, w26, uxtw]

LDSTx ..., [xM]

add x28, x27, wM, uxtw
LDSTx ..., [x28]

LDSTx ..., [xM, #I]

add x28, x27, wM, uxtw
LDSTx ..., [x28, #I]

LDSTx ..., [xM, #I]!

add x28, x27, wM, uxtw
LDSTx ..., [x28, #I]
add xM, xM, #I

LDSTx ..., [xM], #I

add x28, x27, wM, uxtw
LDSTx ..., [x28]
add xM, xM, #I

LDSTx ..., [xM1], xM2

add x28, x27, wM1, uxtw
LDSTx ..., [x28]
add xM1, xM1, xM2

Stack pointer modification#

When the stack pointer is modified, we write the modified value to a temporary, before moving it back into sp with a safe add.

mov sp, xN

add sp, x27, wN, uxtw

{add,sub} sp, sp, {#I,xN}

{add,sub} x26, sp, {#I,xN}
add sp, x27, w26, uxtw

Link register modification#

When the link register is modified, it is guarded back into the sandbox with a safe add x30, x27, w30, uxtw. This guard is deferred until the next control-flow instruction rather than emitted immediately after the modification. Deferral keeps a signed return address intact so that a following authentication instruction (such as autiasp) can run before the guard, which would otherwise destroy the pointer authentication signature. See Pointer Authentication Code (PAC) support.

ldr x30, [...]
ret

ldr x30, [...]
add x30, x27, w30, uxtw
ret

ldp xN, x30, [...]
ret

ldp xN, x30, [...]
add x30, x27, w30, uxtw
ret

Pointer Authentication Code (PAC) support#

LFI is compatible with Arm Pointer Authentication Code (PAC) instructions, which are used to sign and authenticate x30 to protect against control-flow hijacking.

The typical use is -mbranch-protection=pac-ret, which signs only the return address in x30 using the hint-space paciasp and autiasp instructions. The combined authenticate-and-branch and authenticate-and-return instructions covered below require Armv8.3-a and are not produced by -mbranch-protection. They can appear in hand-written assembly or from environments that sign all code pointers, so the rewriter still sandboxes them rather than passing them through unmodified.

To gain the security benefit of PAC under LFI, the hardware must implement FEAT_FPAC, so that authentication failures fault immediately. Without FEAT_FPAC, a failed authentication produces a poisoned pointer, which LFI still keeps confined to the sandbox by masking it, but the mask overwrites the poison caused by the authentication failure.

paciasp

paciasp

autiasp
ret

autiasp
add x30, x27, w30, uxtw
ret

Authenticated returns (retaa/retab) combine authentication with return, and must be expanded during rewriting.

retaa

autiasp
add x30, x27, w30, uxtw
ret

retab

autibsp
add x30, x27, w30, uxtw
ret

Authenticated branches (braa/brab/braaz/brabz) and calls (blraa/blrab/blraaz/blrabz) combine authentication with an indirect branch or call. They are expanded by first authenticating the target register in place, then performing a normal sandboxed branch or call.

braa xN, xM

autia xN, xM
add x28, x27, wN, uxtw
br x28

braaz xN

autiza xN
add x28, x27, wN, uxtw
br x28

blraa xN, xM

autia xN, xM
add x28, x27, wN, uxtw
blr x28

Authenticated exception returns (eret/eretaa/eretab) are privileged and are not supported: the rewriter reports an error for them.

System instructions#

System calls are rewritten into a sequence that loads the address of the first runtime call entrypoint and jumps to it. The runtime call entrypoint table is stored at a negative offset from the sandbox base, so it can be referenced by x27. The rewrite also saves and restores the link register, since it is used for branching into the runtime.

svc #0

mov x26, x30
ldur x30, [x27, #-8]
blr x30
add x30, x27, w26, uxtw

Thread pointer (TP)#

TP accesses are rewritten into loads/stores from the context register (x25), which holds the virtual thread pointer at offset 16 (see Context Register).

Basic guard elimination#

If a register is guarded multiple times in the same basic block without any modifications to it during the intervening instructions, then subsequent guards can be removed.

add x28, x27, wN, uxtw
ldur xN, [x28]
add x28, x27, wN, uxtw
ldur xN, [x28, #8]
add x28, x27, wN, uxtw
ldur xN, [x28, #16]

add x28, x27, wN, uxtw
ldur xN, [x28]
ldur xN, [x28, #8]
ldur xN, [x28, #16]

Address generation#

Note: not yet implemented.

Addresses to global symbols in position-independent executables are frequently generated via adrp followed by ldr. Since the address generated by adrp can be statically guaranteed to be within the sandbox, it is safe to directly target x28 for these sequences. This allows the omission of a guard instruction before the ldr.

adrp xN, target
ldr xN, [xN, imm]

adrp x28, target
ldr xN, [x28, imm]

Stack guard elimination#

Note: not yet implemented.

If the stack pointer is modified by adding/subtracting a small immediate, and then later used to perform a memory access without any intervening jumps, then the guard on the stack pointer modification can be removed. This is because the load/store is guaranteed to trap if the stack pointer has been moved outside of the sandbox region.

add x26, sp, #8
add sp, x27, w26, uxtw
... (same basic block)
ldr xN, [sp]

add sp, sp, #8
... (same basic block)
ldr xN, [sp]

Guard hoisting#

Note: not yet implemented.

In certain cases, guards may be hoisted outside of loops.

    mov w8, #10
    mov w9, #0
.loop:
    add w9, w9, #1
    ldr xN, [xM]
    cmp w9, w8
    b.lt .loop
.end:

    mov w8, #10
    mov w9, #0
    add x28, x27, wM, uxtw
.loop:
    add w9, w9, #1
    ldr xN, [x28]
    cmp w9, w8
    b.lt .loop
.end:

Terminology#

In the following assembly rewrites, some shorthand is used.

• %rN or %eN: refers to any general-purpose non-reserved register.

• %vN: refers to any vector register.

• {a,b,c}: matches any of a, b, or c.

• N(...): refers to any memory addressing mode.

• N: refers to any displacement, including none.

• S: refers to any scale.

• Op: refers to any instruction with a memory operand.

• MOD: refers to any instruction that writes the stack pointer.

• x?: matches an optional x.

Control flow#

Indirect jumps are rewritten to first apply a mask that zeroes the top 32 bits and bottom 5 bits of the target. An addq instruction is then used to fill in the top 32 bits with the sandbox base, producing an address that is both inside the sandbox and bundle-aligned.

Indirect branches through memory first load the branch target into the scratch register (%r11), and then dispatch through it. That load is itself sandboxed by the memory access rewrite below.

Returns are rewritten to pop the return address into the scratch register, followed by a sandboxed indirect jump.

Direct jumps and direct calls do not need to be rewritten, since their targets are resolved at link time. Direct calls are placed at the end of a bundle.

jmpq *%rX

andl $-32, %eX
addq %r14, %rX
jmpq *%rX

jmpq *N(%rX)

movq %gs:N(%eX), %r11
andl $-32, %r11d
addq %r14, %r11
jmpq *%r11

callq *%rX

andl $-32, %eX
addq %r14, %rX
callq *%rX

callq *N(%rX)

movq %gs:N(%eX), %r11
andl $-32, %r11d
addq %r14, %r11
callq *%r11

ret

popq %r11
andl $-32, %r11d
addq %r14, %r11
jmpq *%r11

Memory accesses#

Memory accesses are confined to the sandbox by rewriting the addressing mode. The address is computed from 32-bit registers, so that it wraps within the 4GiB sandbox rather than escaping it, and a %gs segment override supplies the sandbox base.

An access based on a register that always holds an address inside the sandbox is already safe, and is left alone. Those registers are %rsp, %rip, and %r14.

Every addressing mode is rewritten, except those that encode an address without dereferencing it, such as lea and multi-byte nops.

Only the addressing mode changes, so the rewrites are listed as addressing modes rather than whole instructions.

N(%rX)

%gs:N(%eX)

N(%rX, %rY, S)

%gs:N(%eX, %eY, S)

N(, %rY, S)

%gs:N(, %eY, S)

N

N(%r14)

N({%rsp,%rip,%r14})

N({%rsp,%rip,%r14})

leaq N(...), %rX

leaq N(...), %rX

String instructions also address memory implicitly, but they can be rewritten and are covered below.

Gather and scatter index memory with a vector register, which holds a separate offset for every element rather than part of one address. The index therefore keeps its width and only the base is truncated, since the 32-bit address size makes each element’s address wrap within the sandbox just as a scalar one does. A vector index cannot give the access a 32-bit address size on its own, so an access with no base register gets %r14d, whose value is zero because the sandbox base is 4GiB-aligned.

N(%rX, %vY, S)

%gs:N(%eX, %vY, S)

N(, %vY, S)

%gs:N(%r14d, %vY, S)

String instructions#

String instructions address memory through %rdi and %rsi, which cannot be replaced by an addressing mode, so the registers themselves are guarded before the access. The guard truncates the pointer to a sandbox offset and adds the sandbox base back with a lea, which does not disturb the flags.

The guards and the access must be in the same bundle, so that control cannot enter between them.

movs and cmps access memory through both registers, stos and scas through %rdi alone, and lods through %rsi alone.

rep? {stos,scas}

.bundle_lock
movl %edi, %edi
leaq (%r14, %rdi), %rdi
rep? {stos,scas}
.bundle_unlock

rep? lods

.bundle_lock
movl %esi, %esi
leaq (%r14, %rsi), %rsi
rep? lods
.bundle_unlock

rep? {movs,cmps}

.bundle_lock
movl %edi, %edi
leaq (%r14, %rdi), %rdi
movl %esi, %esi
leaq (%r14, %rsi), %rsi
rep? {movs,cmps}
.bundle_unlock

Stack modification#

The stack pointer must always hold an address inside the sandbox, so an instruction that writes it is demoted to its 32-bit form, which clears the top 32 bits, and the sandbox base is then added back. As above, the lea form of the addition is used so that the flags are left alone. Both halves must be in the same bundle, so that control cannot enter with an unsandboxed %rsp.

The rewrite recognizes mov, lea, add, sub, and, or, and xor, and reports an error for any other instruction that writes the stack pointer. push and pop move the stack pointer by a fixed amount and perform an access, which traps if it exits the sandbox, so they are not rewritten.

MOD ..., %rsp

.bundle_lock
MOD ..., %esp
leaq (%rsp, %r14), %rsp
.bundle_unlock

System instructions#

System calls are rewritten into a sequence that loads the return address into the scratch register and jumps to the runtime call handler. The runtime call handler table is stored at the address pointed to by r14. The r11 register stores the return address (marked by the label .Ltmp in the block below).

syscall

leaq .Ltmp(%rip), %r11
jmpq *-8(%r14)
.Ltmp:

Thread pointer#

Thread pointer accesses via the %fs segment (used for TLS) are rewritten to use the virtual thread pointer from the context register (r15) at offset 16 (see Context Register). The rewrite handles any load or store instruction with an %fs-segment memory operand.

The thread pointer is an address inside the sandbox like any other, so the resulting access is sandboxed by the memory access rewrite above. A bare %fs:0 is the exception: it becomes an access to the context register itself, which the runtime maintains outside the sandbox, and so is left unsandboxed.

Op %fs:0, %rD

Op 16(%r15), %rD

Op %fs:(%rX), %rD

movq 16(%r15), %rD
Op %gs:(%eD, %eX), %rD

Op %rS, %fs:(%rX)

movq 16(%r15), %r11
Op %rS, %gs:(%r11d, %eX)

Op %fs:N(%rX, %rY, S), %rD

movq 16(%r15), %r11
leaq (%r11, %rX), %r11
Op %gs:N(%r11d, %eY, S), %rD

Op %rS, %fs:N(%rX, %rY, S)

movq 16(%r15), %r11
leaq (%r11, %rX), %r11
Op %rS, %gs:N(%r11d, %eY, S)