Hardware Security Vulnerabilities

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

#!/bin/bash
# Check microcode status and update capability
 
echo "=== CPU Microcode Information ==="
echo ""
 
# Current microcode revision
echo "Current microcode revision:"
grep -m1 "microcode" /proc/cpuinfo
echo ""
 
# CPU identification
echo "CPU Family and Model:"
lscpu | grep -E "^(Vendor|Model name|CPU family|Model:|Stepping)"
echo ""
 
# Check for microcode update kernel messages
echo "Recent microcode updates (dmesg):"
dmesg | grep -i microcode | tail -5
echo ""
 
# Check for available updates (on Debian/Ubuntu)
if command -v apt-cache &> /dev/null; then
    echo "Available microcode packages:"
    apt-cache search microcode | grep -E "(intel|amd)"
fi
 
# Check for Intel-specific mitigation capabilities
echo ""
echo "=== Mitigation Capability Flags (MSRs) ==="
echo "Checking CPU capabilities for speculation control..."
 
# Parse /proc/cpuinfo for relevant flags
echo ""
echo "Speculation control features:"
grep -o -E 'ibrs|ibpb|stibp|ssbd|md_clear|flush_l1d' /proc/cpuinfo | sort -u | while read flag; do
    case $flag in
        ibrs)     echo "  IBRS: Indirect Branch Restricted Speculation" ;;
        ibpb)     echo "  IBPB: Indirect Branch Predictor Barrier" ;;
        stibp)    echo "  STIBP: Single Thread Indirect Branch Predictors" ;;
        ssbd)     echo "  SSBD: Speculative Store Bypass Disable" ;;
        md_clear) echo "  MD_CLEAR: MDS buffer clearing support" ;;
        flush_l1d) echo "  FLUSH_L1D: L1 Data cache flush capability" ;;
    esac
done
 
# Verify update method
echo ""
echo "=== Microcode Loading ==="
if [ -d /sys/devices/system/cpu/microcode ]; then
    echo "Microcode interface available at /sys/devices/system/cpu/microcode"
    if [ -f /sys/devices/system/cpu/microcode/reload ]; then
        echo "Late loading supported (can update at runtime)"
    fi
fi
 
# Show kernel config for early microcode loading
echo ""
echo "Kernel microcode configuration:"
grep -E "CONFIG_MICROCODE" /boot/config-$(uname -r) 2>/dev/null || echo "Config not available"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

/*
 * Retpoline: Safe indirect branch replacement
 * 
 * The goal: call a function whose address is in %rax
 * WITHOUT using an indirect jump that could be mispredicted
 */
 
/*
 * VULNERABLE: Standard indirect call
 * 
 *   call *%rax
 * 
 * The CPU uses the BTB to predict where this call will go.
 * An attacker can train the BTB to redirect speculation to
 * a gadget of their choosing.
 */
 
/*
 * SAFE: Retpoline replacement
 * 
 * Key insight: The Return Stack Buffer (RSB) is separate from
 * the BTB and (at the time) wasn't subject to cross-privilege
 * pollution. We can exploit this by converting indirect jumps
 * into returns.
 */
 
.section .text
.globl __x86_indirect_thunk_rax
.type __x86_indirect_thunk_rax, @function
 
__x86_indirect_thunk_rax:
    /*
     * Step 1: CALL pushes return address to RSB and stack
     *         RSB now predicts the return will go to L2
     */
    call .L1
    
.L2:
    /* 
     * Speculation reaches here because RSB predicted it.
     * This is an infinite loop that occupies the speculative
     * pipeline without doing anything harmful.
     * The LFENCE ensures no speculation leaks occur.
     */
    lfence
    jmp .L2    /* Speculative execution trapped here harmlessly */
    
.L1:
    /*
     * Step 2: Overwrite the stack return address with our target
     *         RSB still thinks we'll return to L2
     */
    mov %rax, (%rsp)
    
    /*
     * Step 3: RET pops the stack (our target) and jumps there
     *         Architecturally: goes to target in %rax
     *         Speculatively: RSB predicts .L2 (infinite loop)
     */
    ret
 
/*
 * What happens:
 * 
 * ARCHITECTURAL PATH (correct):
 *   call .L1 → .L1 → mov → ret → target from %rax
 *   
 * SPECULATIVE PATH (misprediction):
 *   call .L1 → RSB predicts return to .L2 → .L2 → lfence/jmp loop
 *   (Eventually corrected when ret resolves, but speculation was safe)
 * 
 * The attacker cannot redirect speculation to their gadget because:
 * 1. We never use indirect branch prediction (BTB)
 * 2. RSB prediction goes to our safe loop (.L2)
 * 3. Any leaked data during speculation is just from our loop
 */
 
/*
 * RETPOLINE LIMITATIONS:
 * 
 * 1. Retbleed (2022): Researchers found ways to pollute RSB
 *    across privilege boundaries, breaking retpoline
 *    
 * 2. Performance: The extra call/ret overhead is significant
 *    (~5-10% on branch-heavy workloads)
 *    
 * 3. Modern mitigation: eIBRS is preferred when available
 */

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

/*
 * MDS Mitigation: Buffer Clearing with VERW
 * 
 * This is what the Linux kernel does to mitigate MDS vulnerabilities.
 */
 
#include <asm/msr.h>
 
/*
 * Check if MDS mitigation is available
 */
static bool cpu_has_md_clear(void)
{
    unsigned int eax, ebx, ecx, edx;
    
    /* Check for MD_CLEAR capability (CPUID leaf 7, EDX bit 10) */
    cpuid_count(7, 0, &eax, &ebx, &ecx, &edx);
    
    return (edx & (1 << 10)) != 0;
}
 
/*
 * The MDS clearing sequence
 * 
 * When MD_CLEAR is available, VERW clears:
 * - Store buffers
 * - Load ports
 * - Fill buffers
 */
 
/* Data segment selector for VERW */
#define __KERNEL_DS 0x18
 
static inline void mds_clear_cpu_buffers(void)
{
    static const unsigned short ds = __KERNEL_DS;
    
    /*
     * VERW (%ds) - Verify writeable segment
     * 
     * With MD_CLEAR microcode:
     * - Architecturally: Checks if DS is writable (always true)
     * - Microarchitecturally: Also clears CPU buffers!
     * 
     * This is a clever reuse of an existing instruction.
     */
    asm volatile(
        "verw %[ds]"
        : 
        : [ds] "m" (ds)
        : "cc"
    );
}
 
/*
 * Called at security-critical boundaries:
 * - User to kernel transition
 * - VM exit
 * - Before context switch to different security domain
 */
void mds_user_clear_cpu_buffers(void)
{
    if (static_cpu_has(X86_FEATURE_MD_CLEAR)) {
        mds_clear_cpu_buffers();
    }
}
 
/*
 * L1 Data Cache Flush
 * 
 * For L1TF (L1 Terminal Fault), clearing stores buffers isn't enough.
 * We need to flush the entire L1 data cache.
 */
static inline void flush_l1d(void)
{
    /*
     * IA32_FLUSH_CMD MSR (0x10B) - L1D_FLUSH
     * 
     * Writing 1 to this MSR flushes L1D cache.
     * Requires microcode support.
     */
    wrmsrl(MSR_IA32_FLUSH_CMD, L1D_FLUSH);
}
 
/*
 * This is called on VM exit when running untrusted guests
 * to prevent L1TF attacks
 */
void vmx_l1d_flush(struct kvm_vcpu *vcpu)
{
    if (vmx_l1d_flush_required()) {
        if (static_cpu_has(X86_FEATURE_FLUSH_L1D)) {
            flush_l1d();
        } else {
            /* Software fallback: read through cache to evict */
            vmx_l1d_flush_software();
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

/*
 * PTE Inversion: L1TF Mitigation in Linux
 * 
 * The Problem:
 * When a PTE has Present=0, the CPU ignores most other bits.
 * But L1TF speculatively uses the physical address bits!
 * 
 * Attack scenario:
 * 1. Attacker creates a non-present PTE with controlled phys addr bits
 * 2. Attacker accesses that virtual address (will fault)
 * 3. CPU speculatively accesses L1 cache using those phys addr bits
 * 4. Attacker recovers L1 cache contents via cache side-channel
 */
 
/*
 * The Solution: PTE Inversion
 * 
 * When swapping out or unmapping a page, instead of leaving
 * the physical address in the PTE, we INVERT all bits.
 * 
 * This means the "physical address" seen during speculation
 * is 0xFFFFFFFFFF... which is guaranteed to NOT be in L1 cache
 * (it's beyond the addressable range).
 */
 
#define PTE_INVERT_MASK  ((1UL << 52) - 1)  /* Bits 0-51 */
 
/*
 * When making a PTE non-present (e.g., for swap):
 */
pte_t pte_mk_non_present(pte_t pte)
{
    pte_t new_pte;
    
    /* Clear present bit */
    new_pte = pte_clear_flags(pte, _PAGE_PRESENT);
    
    /* Invert the physical address bits */
    /* This makes the speculative "address" point to nothing */
    new_pte.pte ^= PTE_INVERT_MASK;
    
    return new_pte;
}
 
/*
 * When restoring a PTE (e.g., swap-in):
 */
pte_t pte_mk_present(pte_t pte)
{
    pte_t new_pte;
    
    /* De-invert the physical address bits */
    pte.pte ^= PTE_INVERT_MASK;
    
    /* Set present bit */
    new_pte = pte_set_flags(pte, _PAGE_PRESENT);
    
    return new_pte;
}
 
/*
 * Why this works:
 * 
 * Before inversion:
 *   PTE = 0x0000000012345000 (points to frame 0x12345)
 *   After clear present: speculation uses 0x12345 → L1TF!
 *   
 * After inversion:
 *   PTE = 0xFFFFFFFEDCBAFFFx (inverted)
 *   After clear present: speculation uses 0xEDCBA... → not in memory!
 */

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

/*
 * ARM Security Mitigations Overview
 * 
 * ARM provides several architectural features for security,
 * implemented in Cortex-A76, A77, and later cores.
 */
 
/* SSBS: Speculative Store Bypass Safe */
#define SSBS_BIT  (1UL << 12)
 
void enable_ssbs(void)
{
    /* Set SSBS bit in PSTATE */
    asm volatile(
        "msr SSBS, #1"
        ::: "cc"
    );
    /*
     * When SSBS=1, speculative store bypass is disabled.
     * Loads cannot speculatively bypass older stores.
     */
}
 
/* Branch Target Identification (BTI) */
/*
 * BTI adds landing pad instructions that must be the
 * target of indirect branches. Jumping elsewhere faults.
 * 
 * Valid landing pads:
 * - BTI C: Valid target for CALL (BLR)
 * - BTI J: Valid target for JUMP (BR)
 * - BTI JC: Valid for either
 * 
 * Compiler generates these automatically when enabled.
 */
 
void secure_function(void) __attribute__((target("branch-protection=bti")))
{
    /* Compiler inserts BTI landing pad here */
    /* Function body */
}
 
/* Pointer Authentication Codes (PAC) */
/*
 * PAC uses a secret key to sign pointers (especially return addresses).
 * Branch/return instructions verify the signature and fault if invalid.
 * 
 * This makes ROP (Return Oriented Programming) much harder.
 */
 
void pac_protected_function(void)
    __attribute__((target("branch-protection=pac-ret")))
{
    /*
     * Compiler generates:
     * - PACIASP: Sign LR on function entry
     * - AUTIASP: Verify LR on function return
     * 
     * If an attacker overwrites the return address,
     * AUTIASP will fail and cause a fault.
     */
}
 
/* Speculation Barrier */
void speculation_barrier_arm(void)
{
    /*
     * CSDB: Consumption of Speculative Data Barrier
     * 
     * Ensures that conditional instructions after CSDB
     * don't use speculatively loaded data.
     */
    asm volatile("csdb" ::: "memory");
    
    /*
     * Used after array bounds checks:
     *   if (index < size) {
     *       __asm__ __volatile__("csdb");
     *       data = array[index];  // Safe from speculation
     *   }
     */
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

#!/bin/bash
# Script to analyze and recommend mitigation settings
 
echo "=== Current System Mitigation Analysis ==="
echo ""
 
# Get CPU info
VENDOR=$(grep -m1 "vendor_id" /proc/cpuinfo | awk '{print $3}')
MODEL=$(grep -m1 "model name" /proc/cpuinfo | cut -d: -f2 | xargs)
STEPPING=$(grep -m1 "stepping" /proc/cpuinfo | awk '{print $3}')
 
echo "CPU: $MODEL"
echo "Vendor: $VENDOR"
echo ""
 
# Check current mitigations
echo "Current vulnerability status:"
for f in /sys/devices/system/cpu/vulnerabilities/*; do
    vuln=$(basename $f)
    status=$(cat $f)
    printf "  %-20s %s
" "$vuln:" "$status"
done
 
echo ""
echo "=== Performance-Oriented Recommendations ==="
 
# Intel-specific advice  
if [ "$VENDOR" == "GenuineIntel" ]; then
    echo "Intel CPU Detected"
    echo ""
    
    # Check for hardware fixes
    if grep -q "Not affected" /sys/devices/system/cpu/vulnerabilities/meltdown 2>/dev/null; then
        echo "✓ Hardware Meltdown fix present - KPTI overhead minimal"
    else
        echo "⚠ Software Meltdown mitigation (KPTI) active - expect syscall overhead"
        echo "  Consider: Boot with 'pti=off' only if you trust all running code"
    fi
    
    # Check for eIBRS
    if grep -q "Enhanced IBRS" /sys/devices/system/cpu/vulnerabilities/spectre_v2 2>/dev/null; then
        echo "✓ Enhanced IBRS available - Spectre V2 mitigation is efficient"
    else
        echo "⚠ Using Retpoline or IBRS - moderate overhead on indirect branches"
        echo "  Consider: Upgrade to newer CPU for eIBRS support"
    fi
fi
 
# AMD-specific advice
if [ "$VENDOR" == "AuthenticAMD" ]; then
    echo "AMD CPU Detected"
    echo ""
    echo "✓ Meltdown: Not affected (no KPTI overhead needed)"
    echo "✓ L1TF: Not affected"
    echo "✓ MDS: Not affected"
    echo ""
    echo "Note: Spectre mitigations still apply. Check for Zen3+ for best performance."
fi
 
echo ""
echo "=== Workload-Specific Recommendations ==="
echo ""
echo "High-Frequency Trading / Latency-Critical:"
echo "  - Consider 'mitigations=off' (understand the risk)"
echo "  - Or: Disable SMT + kernel isolation"
echo ""
echo "Cloud/Multi-Tenant:"
echo "  - Keep ALL mitigations enabled"
echo "  - Consider core scheduling for SMT safety"
echo ""
echo "Single-User Workstation:"
echo "  - Default 'auto' is typically appropriate"
echo "  - SMT can usually stay enabled"