Come faccio a verificare se KPTI è abilitato su linux?

Cose che indicano lo stato di KPTI:

• Nei kernel standard, le stringhe Kernel/User page tables isolation: enabled o Kernel/User page tables isolation: force enabled on command line nell'output dmesg indicano che il kernel sta eseguendo l'isolamento della tabella delle pagine del kernel. Quest'ultimo messaggio significa inoltre che il kernel pensa che l'isolamento della tabella di pagina non sia richiesto per questa CPU.

• In alcuni kernel con patch del fornitore (principalmente RedHat e derivati): un valore diverso da zero in /sys/kernel/debug/x86/pti_enabled . L' assenza di questo file non significa nulla, tuttavia: il kernel standard non lo fornisce.

• Nel kernel 4.14.18 o successivi e le versioni corrispondenti dei kernel LTS, il contenuto di /sys/devices/system/cpu/vulnerabilities/meltdown : una riga che inizia con Mitigation: indica che una mitigazione (KPTI, microcodice o qualcos'altro) è al posto, una riga che inizia con Not affected indica che la CPU non è interessata dal problema e una riga che inizia con Vulnerable indica che la CPU è ritenuta vulnerabile, ma nessuna o una mitigazione insufficiente è in atto .

Cose che non indicano lo stato di KPTI:

• Versione del kernel. Il kernel 4.14.11 e successivi, e le versioni corrispondenti dei kernel 4.1, 4, 4 e 4.9 LTS sono capaci di KPTI, ma possono essere compilati con esso disabilitati e possono essere disabilitati a tempo di avvio. Inoltre, le versioni più vecchie di queste non sono automaticamente a rischio: alcune distribuzioni hanno fatto il backport delle patch KPTI ai kernel più vecchi.

• bugs : cpu_insecure in /proc/cpuinfo . La presenza di questo indica che se il kernel è compilato per l'isolamento della tabella di pagina, e se l'isolamento della tabella di pagina non è stato disabilitato all'avvio o al runtime, quindi pagina verrà utilizzato l'isolamento automatico. Inoltre, non indica che una CPU è vulnerabile all'attacco di Meltdown: il kernel 4.14.11 lo imposta per tutte le CPU x86, mentre il kernel 4.14.12 lo imposta per tutte le CPU non AMD, anche quelli come il Pentium MMX o le CPU Atom "Bonnell" che non sono vulnerabili.

• CONFIG_PAGE_TABLE_ISOLATION=y nella configurazione del kernel. Questo indica solo che il kernel è in grado di isolare la tabella di paging del kernel. KPTI può essere disabilitato all'avvio dalla riga di comando del kernel attraverso le opzioni nopti o pti=off . Su alcuni sistemi, può essere disabilitato in fase di runtime scrivendo 0 in /sys/kernel/debug/x86/pti_enabled .

Il kernel di Linux registra lo stato di KPTI all'avvio in modo che, eseguendo il seguente comando, venga stampato lo stato su kernel rattoppati. Se non stampa nulla, KPTI è disabilitato.

dmesg -wH | grep 'Kernel/User page tables isolation'

Linux Kernel 4.15rc6 ha abilitato KPTI (isolamento della tabella-tabella del kernel) ed è stato back ported to Linux Kernel 4.14.11 , 4.9.74, 4.4.109, 3.16.52 e 3.2.97.

Quindi, se stai utilizzando una di queste versioni, KPTI è installato. La maggior parte delle distro (eseguendo qualsiasi versione del kernel di Linux) invierà un aggiornamento al kernel Linux entro un giorno o due per risolvere Meltdown e lo spettro.

Nota: aggiungi il parametro pti=off a GRUB per disabilitare KPTI. Per informazioni: link

Su un kernel supportato:

dmesg | grep 'Kernel / User pages tables isolation'

risulterà abilitato o disabilitato.

Se non ci sono risultati, il kernel non ha il supporto per KPTI.

Controlla l'output di dmesg, come dmesg | grep isolation , per determinare se è attivato per la tua macchina in esecuzione.

Alcuni ulteriori dettagli sono menzionati qui: link

• Sarà disponibile un'opzione della riga di comando nopti per disabilitare questo meccanismo al momento dell'avvio.
• C'è l'opzione del kernel PAGE_TABLE_ISOLATION che abilita le patch KPTI, e se CONFIG_IKCONFIG è abilitato puoi controllare il kernel in esecuzione di zcat /proc/config.gz | grep CONFIG_PAGE_TABLE_ISOLATION=y
• Esiste un flag di funzionalità X86_BUG_CPU_INSECURE, e se la CPU non risente del fatto che l'isolamento della tabella di pagine è disattivato.

Verifica la presenza di una riga contenente Kernel/User page tables isolation in dmesg output. Ma poiché l'inizio del kernel ring buffer potrebbe non esserci più, un'altra possibilità è cercare la stessa stringa in /var/log/kern.log (o una delle sue versioni ruotate, o qualche altro file di log).

Si noti inoltre che gli ospiti Xen potrebbero non avere tale linea. Ad esempio, questo è il caso silent_disable in arch/x86/mm/kaiser.c del kernel Debian / stretch (4.9.65-3 + deb9u2):

void __init kaiser_check_boottime_disable(void)
{
[...]
        if (boot_cpu_has(X86_FEATURE_XENPV))
                goto silent_disable;
[...]
disable:
        pr_info("disabled\n");

silent_disable:
        kaiser_enabled = 0;
        setup_clear_cpu_cap(X86_FEATURE_KAISER);
}

Sono preoccupato anche per l'impatto sulle prestazioni del patch di fusione. Gestiamo la maggior parte del carico di lavoro su Amazon Linux su EC2.

Ho notato che l'aggiornamento del kernel più recente (build 03 Jan 2018) - 4.9.70-25.242 include tutte le patch di fusione a monte (controlla rpm -q --changelog kernel ).

Di default il kernel di Amazon Linux 4.9.70-25.242 e successivi abilita l'isolamento della tabella di pagine ( CONFIG_PAGE_TABLE_ISOLATION=y ), quindi suppongo che finché questo flag è y, KPTI è abilitato, sfortunatamente. Non ho fatto alcun confronto con le differenze di performance (dovrebbe essere evidente)