Arresto anomalo durante l'avvio su un recente computer aziendale

Dopo alcuni aggiornamenti recenti, il mio computer non si avvia più! Ecco cosa potrei determinare:

• Questo è un computer molto recente che mi è stato fornito dall'IT aziendale. Ha una recente CPU Intel (generazione Skylake).
• Il computer esegue Ubuntu 16.04.
• L'ultimo avvio del computer è stato eseguito correttamente a marzo. Il problema è presumibilmente dovuto a un aggiornamento del software o a un bug hardware.
• Ho un altro computer con 16.04 con praticamente lo stesso software installato (che ho usato apt-clone), e funziona perfettamente. Ha hardware diverso (anche amd64, ma CPU diversa, GPU diversa, ecc.).
• Il kernel si avvia, initrd funziona correttamente. Quando avvio con una schermata iniziale in modalità grafica, mi viene richiesta la password per il mio volume dm-crypt e l'ultima cosa che vedo è che è montato correttamente.
• Il blocco si verifica prima che riceva un prompt di accesso. Quando il computer si blocca, è un blocco duro. Anche Alt+ SysRqnon risponde. La CPU è evidentemente bloccata al 100% da quando le ventole si accendono al massimo.
• Ho ancora il kernel che stavo eseguendo prima di riavviare. Quando seleziono questo kernel nel menu di Grub, ottengo lo stesso blocco. Quindi sembra che questo sia un bug del kernel preesistente che viene attivato da qualcos'altro - ma cosa?
• Se spengo la schermata iniziale (rimuovo splashdalla linuxriga di comando in Grub), vedo l'avvio di un numero di servizi, quindi si blocca.

• Posso ottenere una shell di root aggiungendola init=/bin/shalla linuxriga di comando in Grub. Posso anche andare oltre aggiungendo

  systemd.unit=basic.target systemd.shell
  

  Questo avvia un numero di servizi ed esegue una shell di root su tty9.

• Se corro systemctl start multi-user.targetda quella shell di root, il computer si blocca. Quindi presumibilmente il problema è innescato da uno di questi servizi.
• Corsi systemctl list-dependencies multi-user.targeta vedere quali servizi iniziarono. Ho avviato manualmente le dipendenze elencate una per una e tutto è iniziato bene.

Quindi questo sembra un bug hardware (poiché si verifica su un computer ma non sull'altro) che viene attivato da alcuni software. Ma quale software? Dal momento che il computer si blocca così duramente, non riesco a ottenere alcun registro. Non riesco nemmeno a ottenere alcun risultato utile sulla console.

Utili tecniche di debug:

• Alt+ SysRq: tasto magico SysRq , che consente di eseguire operazioni come il riavvio di emergenza. Accede al kernel a un livello molto basso, quindi funziona in tutti gli arresti anomali tranne quelli peggiori. Nel mio caso, Alt+ SysRqnon risponde, il che dimostra quanto è profondo lo schianto.
• Per modificare i parametri di avvio, tenere premuto Shiftalcuni secondi dopo l'accensione. È necessario premerlo dopo che il BIOS ha inizializzato la tastiera, ma prima dell'avvio del sistema operativo. Questo fa apparire il menu Grub .
• Nel menu di Grub, premere eper modificare la riga di comando per una voce di menu. Per modificare i parametri di avvio di Linux, passare alla riga che inizia con linux. Su un moderno Ubuntu, troverai i vecchi kernel in "Opzioni avanzate per Ubuntu". Dopo aver apportato le modifiche desiderate alla riga di comando, premere Ctrl+ xper avviare. Tutte le modifiche apportate qui sono solo per questo avvio, non vengono salvate sul disco.
• Alcune opzioni utili sulla linuxriga di comando:
  • quiet nosplashnasconde quasi tutti i messaggi di avvio. Rimuoverli per ottenere messaggi sulla console durante l'avvio, che è necessario per avere qualsiasi possibilità di diagnosticare i problemi.
  • recoveryti dà una shell di root con quasi nessun servizio. Dovrai conoscere la password di root. La voce di menu "modalità di ripristino" utilizza questo.
  • init=/bin/shti dà una shell di root senza alcun servizio. Per riprendere il normale avvio, eseguire exec init. A questo punto puoi passare le opzioni di systemd, ad esempio exec init --unit=basic.targetper avviare init e alcuni servizi (tieni presente che questo non inizia in alcun modo ad accedere, quindi è meglio avere una shell in esecuzione su un'altra console). Si noti che il filesystem di root è montato in sola lettura; corri mount -o remount,rw /per poterti scrivere.
  • systemd.unit=basic.targetavvia un set di servizi molto semplice. Nota che questo non include alcun modo per accedere! Puoi impostarlo come predefinito eseguendolo systemctl set-default basic.targetal prompt di root. Per ripristinare la destinazione predefinita originale, eseguire systemctl set-default graphical.target(o systemctl set-default multi-user.targetper un server senza GUI).
  • systemd.debug-shellavvia una shell di root su tty9. È possibile abilitare questo per ogni avvio eseguendo systemctl enable debug-shellun prompt di root. Non dimenticare di disabilitarlo dopo aver risolto il problema systemctl disable debug-shell. Premi Alt+ F9per passare a tty9.
  • Vedi anche Fedora systemd suggerimenti , consigli problema di avvio di Arch Linux .

Il problema

Si scopre che il mio problema è un problema noto tra l'ultimo microcodice Intel su (alcune?) CPU Skylake e recenti kernel Linux, che è principalmente innescato da sssd . Vedi il bug # 1759920 di Ubuntu “intel-microcode 3.20180312.0 causa il blocco nella schermata di accesso (w / linux-image-4.13.0-37-generic)” , e anche una serie di altri bug che si rivelano essere circa lo stesso problema , come il bug # 1746806 di Ubuntu "sssd sembra arrestare in modo anomalo le istanze AWS c5 e m5, causare il 100% di CPU" e il bug Ubuntu # 1746418 "Il sistema si blocca all'avvio di Xorg dopo l'installazione di linux-image-4.13.0-32-generic" . È probabile che si verifichi questo errore se:

• Hai una CPU Intel molto recente. Per quanto ne so, questo errore si presenta solo sulle CPU Skylake .
• Hai installato il pacchetto micro-codice Intel . Il ripristino di un kernel testato in precedenza non ha funzionato per me perché eseguivo quel kernel solo con un microcodice precedente.
• Il computer è collegato a una rete aziendale (in genere LDAP o Active Directory) per l'autenticazione dell'utente. Sebbene esistano altri modi per attivare il bug, l'esecuzione di sssd sembra essere il colpevole più comune. Ci sono anche segnalazioni di crash di Xorg .

Il bug è dovuto alle mitigazioni del problema di sicurezza di Spectre pubblicato a gennaio 2018. Esiste un'incompatibilità tra un po 'di codice del kernel e un microcodice del processore che provoca un blocco in determinate circostanze.

Come riparare

1. Se non riesci ad avviare normalmente, dovrai modificare la riga di comando del kernel al prompt di Grub. Vedi la domanda per spiegazioni e possibili modi per ottenere una shell di root.
2. Una soluzione alternativa per questo specifico bug è aggiungere il noibpbparametro alla riga di comando del kernel ( 1746418/14 , 1759920/56 ). Ciò dovrebbe consentire l'avvio normale ed eseguire alcune riparazioni.
   Questo disabilita l'attenuazione della vulnerabilità che causa il problema, il che significa che il tuo computer è ora vulnerabile ad alcuni attacchi. Sono attacchi locali, ovvero l'attaccante deve eseguire il codice sul tuo computer, ma questi attacchi possono essere potenzialmente eseguiti, ad esempio, tramite JavaScript in un browser web.
   Se non hai altri modi, puoi renderlo permanente aggiungendo noibpballa riga di comando del kernel fino a quando non puoi ottenere un kernel fisso.
3. In Ubuntu, la correzione è prevista nella settimana del 23 aprile 2018 , in quello che presumibilmente sarà il kernel 4.4.0-117 e 4.13.0-39. Nel frattempo, Tyler Hicks ha pubblicato kernel di test per 4.4 e 4.13 .

Come ho diagnosticato il problema

Ho provato diverse cose (vedi la domanda) e ho determinato che il bug era stato attivato da qualche parte tra raggiungere basic.targete raggiungere multi-user.target. Quindi ho impostato la destinazione systemd predefinita su basic.target( systemctl set-default basic.target) e abilitato il debug-shellservizio ( systemctl enable debug-shell) per ottenere una shell di root.

Ho corso systemctl list-dependencies multi-user.targete avviato manualmente le dipendenze elencate una per una. Ciò non ha innescato l'incidente.

Non tutti i servizi sono gestiti direttamente da systemd . Alcuni sono gestiti come servizi Upstart e altri sono gestiti come script SysVinit . Lo script di shell di seguito li esegue tutti. Nota: l'ho provato solo una volta ed è andato in crash in base alla progettazione.

#!/bin/sh
wants=$(systemctl show -p Wants multi-user.target | sed 's/^Wants=//' | tr ' ' '\n' | sort)
log=/var/tmp/multi-user-steps-$(date +%Y%m%d-%H%M%S)

log () {
  echo "$* ..." | tee -a "$log"
  sync
  "$@"
  ret=$?
  echo "$* -> $ret" | tee -a "$log"
  sync
  return $ret
}

# systemd services
for service in $wants; do
  log systemctl start $service
  sleep 2
done

# upstart services
for conf in /etc/init/*.conf; do
  service=${conf##*/}; service=${service%.conf}
  log service ${service} start
  sleep 2
done

# sysvinit services
for service in /etc/rc3.d/S*; do
  log ${service} start
  sleep 2
done

Il mio computer si è arrestato in modo anomalo dopo l'avvio sssd. Da lì, una ricerca web su "sssd linux kernel hang" mi ha portato a https://bugs.launchpad.net/cloud-images/+bug/1746806 e alla diagnosi e soluzione.