Assembly and Low-Level Language Fundamentals Questions

Requirements / goal: prevent attackers from chaining existing code snippets (gadgets) by making returns and indirect control-flow transfers harder to forge, while balancing performance, compatibility and ease of deployment.

Compiler-inserted mitigations

• Stack canaries: compiler (e.g., -fstack-protector) places a random sentinel before saved return address or function-scope buffers and checks it at function exit. Low overhead for most functions; bypassable for non-contiguous memory corruption or infoleak that reveals canary. Implementation: add canary load/store and conditional branch to terminate on mismatch.
• Shadow stacks: compiler emits paired instructions that push a copy of return addresses to a protected shadow stack and validate/pop on return. Can be implemented as a separate memory region with stricter protections (W^X, mapped read-only to regular code). Strong against ROP that tampers saved return addresses. Overhead: moderate (extra memory, two writes/reads per call/return); needs ISA support or fast thread-local shadow stack to reduce cost.
• Control Flow Integrity (CFI): compiler builds a CFG and inserts checks before indirect calls/returns to ensure target belongs to allowed set (fine-grained) or type-based (coarse-grained). Enforceable via labels and compare/jump sequences. Fine-grained CFI gives stronger security but requires whole-program analysis or LTO; coarse-grained easier to deploy but weaker.
• Return checks / epilogue hardening: replace ret with verified indirect jump sequence (compare with shadow-stack/top) or use compiler emitted XOR/MAC on return address.

Hardware / ISA features

• Intel CET (Control-flow Enforcement Technology): provides Shadow Stack and Indirect Branch Tracking (IBT). Compiler can emit ENDBR instructions at valid indirect-call targets and use dedicated shadow-stack instructions (call/jmp semantics handled by CPU) to offload checks at near-zero cost and strong security. Deployment requires CPU and OS support.
• ARM Pointer Authentication (PAC): signs pointers (including return addresses and function pointers) with a keyed MAC stored in high bits. Compiler instruments pointer creation and authentication before use (e.g., paciza/autor). Low runtime overhead; needs runtime key management and platform support.

Trade-offs

• Performance: canaries cheap; shadow stacks and CFI add per-call/indirect-call overhead (CFI cost grows with check complexity). Hardware features (CET/PAC) minimize overhead but require modern CPUs.
• Compatibility: fine-grained CFI and shadow stacks often require LTO/whole-program builds and may break dynamic linking, JITs, or third-party binary-only modules. PAC/CET require OS and CPU support; canary works on older hardware.
• Deployability: incrementally deployable mitigations (canaries, coarse CFI) are easier for large codebases. Strong defenses (fine-grained CFI, shadow stacks, PAC/CET) need coordinated toolchain/OS upgrades and may force recompilation.
• Usability & Debugging: additional checks can produce false positives and complicate debugging/profiling; tooling must be updated.

Practical recommendation

• Short term: enable stack canaries and ASLR, compile with coarse-grained CFI where available, adopt sanitizers in CI.
• Medium term: adopt shadow stacks for security-critical modules; require LTO for fine-grained CFI on core binaries.
• Long term: target hardware with CET/PAC, update OS and toolchain to leverage hardware enforcement for minimal overhead and maximal security.

ARM (A32), Thumb (T16/T32), and Thumb-2 are different instruction encodings for ARM CPUs with trade-offs in size, density, and performance.

Definitions & sizes:

• ARM (A32): 32-bit fixed-length instructions. Rich instruction set, full register access, conditional execution.
• Thumb (T16): 16-bit compact instructions (original Thumb). Smaller code size but fewer registers/immediate ranges and fewer addressing modes.
• Thumb-2 (T32): Mixed 16/32-bit encoding that extends Thumb with many 32-bit instructions — combines density of 16-bit encodings where possible and full-feature capability via 32-bit opcodes.

Code density vs performance:

• Thumb (especially T16) gives much better code density (smaller flash footprint) which improves I-cache utilization and reduces memory bandwidth on microcontrollers.
• A32 can be slightly faster per instruction because some operations available only in A32 are single-instruction there but need multiple Thumb instructions; however on modern cores decode/IPC mitigates this and Thumb-2 often matches A32 performance.

Interworking:

• CPUs support a mode bit (T-bit) and branch-to-thumb/branch-to-arm via BX/BLX instructions. Switching switches decoder mode and PC least-significant-bit indicates Thumb. Mode switch has small pipeline penalty; frequent switches hurt performance.

Typical use cases:

• Microcontrollers: Thumb/Thumb-2 preferred for smaller flash, better cache utilization and lower power; many Cortex-M cores only support Thumb-2.
• Application processors: A32 used where maximum per-instruction feature set, predictable performance, and legacy code matter; modern systems often compile hot paths in A32 or use Thumb-2 for a balance.

Practical advice:

• Use Thumb-2 by default on embedded systems for density; measure hotspots and consider ARM mode when specific instruction features or performance are critical.

Static Single Assignment (SSA) form is an IR property where every variable is assigned exactly once and each use refers unambiguously to a single definition. When control flow merges, SSA inserts phi (φ) nodes to choose which incoming definition flows into the merged block. Compilers convert to SSA because the single-assignment property makes dataflow explicit, simplifying many analyses and optimizations (constant propagation, dead-code elimination, value numbering, register allocation).

Example:
Original:
a = 0
if (cond) {
a = 1
}
b = a + 2

SSA with φ:
a0 = 0
if (cond) {
a1 = 1
goto merge
}
goto merge
merge:
a2 = φ(a0, a1) // picks a0 if false, a1 if true
b0 = a2 + 2

Why SSA helps constant propagation:

• In SSA a2 has exactly two known sources. If analysis finds a0 is 0 and a1 is 1, it can determine a2 is either 0 or 1. If one branch is infeasible or both sources equal the same constant, a2 becomes a constant and uses can be replaced directly, enabling further simplification.

Why SSA helps dead-code elimination:

• Each definition has a clear set of uses. If a SSA-defined value has no uses, it is trivially dead and can be removed. Removing it may make its operands unused, enabling a cascade of deletions. The explicit def-use graph makes these reachability checks simple and efficient.

Trade-offs/notes:

• Building SSA requires inserting φ nodes and later reconverting (or handling) for codegen. Modern compilers use SSA because its benefits for optimization outweigh conversion costs.

Brief approach: On Cortex-M an exception entry is handled partly by hardware (automatic stacking of R0–R3,R12,LR,PC,xPSR) and partly by software. A correct ISR in assembly must (1) preserve callee-saved registers (R4–R11, optionally FP regs), (2) save the EXC_RETURN value that hardware put in LR so nested exception returns work, and (3) return by branching to the restored EXC_RETURN (BX LR). Below is a compact Thumb ISR template and explanation.

Assembly ISR (Thumb):

    .syntax unified
    .thumb

    .align 2
    .global My_ISR
My_ISR:
    /* --- entry: hardware already pushed stacked frame: R0-R3,R12,LR,PC,xPSR --- */

    /* Save software-used registers and the EXC_RETURN (in LR) */
    push    {r4-r11, lr}       /* store callee-saved regs and EXC_RETURN */

    /* Now safe to use r0-r3,r12 etc. Do ISR work. Use r0-r3 for scratch. */
    /* Example: call a C-handler: */
    bl      My_C_Handler       /* optional: preserves LR as link; handler must be C-callable */

    /* Restore callee-saved registers and EXC_RETURN */
    pop     {r4-r11, lr}       /* lr now contains original EXC_RETURN */

    /* Return from exception by branching to EXC_RETURN in lr */
    bx      lr                 /* triggers exception return sequence in hardware */

Key concepts / reasoning

• Hardware stacked frame layout (on exception entry, SP points to lowest word):
  • At [SP] : R0
  • [SP + 4] : R1
  • [SP + 8] : R2
  • [SP + 12] : R3
  • [SP + 16] : R12
  • [SP + 20] : LR (return-to)
  • [SP + 24] : PC (return address)
  • [SP + 28] : xPSR
• LR on exception entry contains an EXC_RETURN magic value (0xFFFFFFF1/0xFFFFFFF9/0xFFFFFFFD) describing the return behavior (which stack, whether to restore FP state, target mode).
• If your ISR overwrites LR, you must save it (push lr) and restore before BX lr so the correct EXC_RETURN is used.

EXC_RETURN values (common ones):

• 0xFFFFFFF1 — Return to Handler mode, use MSP (less common to return to handler)
• 0xFFFFFFF9 — Return to Thread mode, use MSP
• 0xFFFFFFFD — Return to Thread mode, use PSP
  (For FP-enabled cores, low-order bits encode FP stack behavior; check ARMv7-M ARM for exact FP EXC_RETURN encodings.)

Nesting support:

• Do not disable interrupts globally (don't set PRIMASK) if you want lower-priority interrupts to preempt.
• Use BASEPRI to mask lower-priority interrupts only if necessary.
• Because each nested exception pushes a new hardware stack frame and a new EXC_RETURN is placed into LR for the new handler, preserving the incoming EXC_RETURN on the stack (push lr) ensures that when you pop it and BX lr you return to the right context (possibly another handler or thread).

FP and extended stacking:

• If using FPU and CONFIGURED to auto-save FP regs, the hardware will stack extra FP state. When pushing/popping, be careful to preserve alignment and follow the appropriate EXC_RETURN FP bits.

Edge cases / best practices:

• Keep ISR prologue/epilogue minimal and deterministic.
• If calling C functions, follow the ABI: save caller-saved regs if your C call expects them preserved.
• Ensure 8-byte stack alignment if calling library code.
• For very short ISRs prefer writing in C with naked/attribute and using compiler prologue macros only if you can guarantee correct save/restore of EXC_RETURN.

Time/space note: The pattern push {r4-r11,lr} uses extra stack (8 registers × 4 bytes = 32 bytes) in addition to hardware 8-word frame (32 bytes).

When writing extended asm in GCC/Clang you must precisely describe how the asm interacts with the compiler so it can schedule/register-allocate correctly. Key points:

• Input/output operands: declare each input ("r"(x)) and output ("=r"(out)) operand. If an asm reads and writes the same operand, use a tied operand: "0"(val) or "+r"(val) to tell the compiler it's the same location.
• Early-clobber: use the '&' constraint if an output must not overlap any input (prevents the compiler from assigning the same register).
• Clobber list: list any registers the asm modifies that are not listed as outputs (e.g., "cc" for flags, "rax" if you use it). Failing to list clobbers lets the compiler assume values in those registers persist → wrong code.
• "memory" clobber: use this when asm reads/writes memory in ways the compiler can't see (prevents reordering/optimizations and forces loads/stores to/from memory).
• "cc" clobber: declare if condition codes/flags are modified.
• volatile: mark asm volatile if it must not be optimized away or reordered relative to surrounding code (e.g., I/O, barriers). Avoid volatile for merely performance-related hints.
• Constraints correctness: choose appropriate constraint letters ("r", "m", "g", "i") and be careful with immediate-only or memory-only constraints.

Example:

int atomic_inc(volatile int *p){
    int old;
    __asm__ volatile(
        "lock; xaddl %0, %1"
        : "+r"(old), "+m"(*p)    /* old is read+write, memory operand is read+write */
        : /* no inputs */
        : "cc", "memory"         /* we modified flags and memory */
    );
    return old;
}

Why mistakes matter:

• Missing clobbers or incorrect operand ties can let the compiler reuse registers or reorder memory accesses, producing subtle, non-deterministic bugs or undefined behavior.
• Mis-specified constraints (e.g., using a register constraint but actually requiring memory) can crash or corrupt data.

Best practices:

• Prefer outputs/input operands over raw clobbering registers.
• Test on target architectures and enable -O2 to catch scheduling issues.
• When in doubt, use "volatile" + "memory" or write a separate function in assembly.