Ciao a tutti, condividiamo con voi la seconda parte della pubblicazione “File system virtuali in Linux: a cosa servono e come funzionano?” Puoi leggere la prima parte . Ricordiamo che questa serie di pubblicazioni è programmata per coincidere con il lancio di un nuovo flusso sul corso , che inizierà molto presto.
Come monitorare VFS utilizzando gli strumenti eBPF e bcc
Il modo più semplice per capire come opera il kernel sui file sysfs è vederlo in pratica, e il modo più semplice per guardare ARM64 è usare eBPF. eBPF (abbreviazione di Berkeley Packet Filter) consiste in una macchina virtuale in esecuzione , che gli utenti privilegiati possono richiedere (query) dalla riga di comando. I sorgenti del kernel dicono al lettore cosa può fare il kernel; l'esecuzione degli strumenti eBPF su un sistema caricato mostra cosa sta effettivamente facendo il kernel.
Fortunatamente, iniziare a utilizzare eBPF è abbastanza semplice con l'aiuto di strumenti , che sono disponibili come pacchetti dalla distribuzione generale e documentato dettagliatamente . Utensili bcc sono script Python con piccoli inserimenti di codice C, il che significa che chiunque abbia familiarità con entrambi i linguaggi può modificarli facilmente. IN bcc/tools Esistono 80 script Python, il che significa che molto probabilmente uno sviluppatore o un amministratore di sistema potrà scegliere qualcosa di adatto a risolvere il problema.
Per avere almeno un'idea superficiale di cosa funzionano i VFS su un sistema in esecuzione, prova vfscount o vfsstat. Questo mostrerà, diciamo, che dozzine di chiamate vfs_open() e i "suoi amici" accadono letteralmente ogni secondo.
vfsstat.pyè uno script Python con inserti di codice C che conta semplicemente le chiamate alle funzioni VFS.
Facciamo un esempio più banale e vediamo cosa succede quando inseriamo una chiavetta USB in un computer e il sistema la rileva.
Usando eBPF puoi vedere cosa sta succedendo in
/sysquando viene inserita un'unità flash USB. Qui viene mostrato un esempio semplice e complesso.
Nell'esempio mostrato sopra, bcc инструмент stampa un messaggio quando viene eseguito il comando sysfs_create_files(). Lo vediamo sysfs_create_files() è stato lanciato utilizzando kworker stream in risposta al fatto che è stata inserita l'unità flash, ma quale file è stato creato? Il secondo esempio mostra la potenza di eBPF. Qui trace.py Stampa un backtrace del kernel (opzione -K) e il nome del file che è stato creato sysfs_create_files(). L'inserimento di una singola istruzione è un codice C che include una stringa di formato facilmente riconoscibile fornita dallo script Python che esegue LLVM compilatore just-in-time. Compila questa riga e la esegue in una macchina virtuale all'interno del kernel. Firma completa delle funzioni sysfs_create_files () deve essere riprodotto nel secondo comando in modo che la stringa di formato possa fare riferimento a uno dei parametri. Gli errori in questa parte di codice C provocano errori riconoscibili dal compilatore C. Ad esempio, se il parametro -l viene omesso, verrà visualizzato il messaggio "Impossibile compilare il testo BPF". Gli sviluppatori che hanno familiarità con C e Python troveranno gli strumenti bcc facile da espandere e modificare.
Quando viene inserita l'unità USB, il backtrace del kernel mostrerà che il PID 7711 è un thread kworkerche ha creato il file «events» в sysfs. Di conseguenza, la chiamata da sysfs_remove_files() mostrerà che la rimozione dell'unità ha comportato l'eliminazione del file events, che corrisponde al concetto generale di conteggio dei riferimenti. Allo stesso tempo, visualizzazione sysfs_create_link () con eBPF durante l'inserimento dell'unità USB verrà visualizzato che sono stati creati almeno 48 collegamenti simbolici.
Allora qual è lo scopo del file degli eventi? Utilizzo Per ricerca , mostra cosa provoca disk_add_events (), e nemmeno "media_change"O "eject_request" può essere registrato in un file evento. Qui il livello del blocco del kernel informa lo spazio utente che un "disco" è apparso ed espulso. Nota quanto sia informativo questo metodo di ricerca inserendo un'unità USB, rispetto al tentativo di capire come funzionano le cose esclusivamente dalla fonte.
I file system root di sola lettura abilitano i dispositivi incorporati
Naturalmente nessuno spegne il server o il proprio computer staccando la spina dalla presa. Ma perché? Questo perché i file system montati sui dispositivi di archiviazione fisici potrebbero avere scritture ritardate e le strutture dati che registrano il loro stato potrebbero non essere sincronizzate con le scritture sull'archiviazione. Quando ciò accade, i proprietari del sistema devono attendere fino al successivo avvio per avviare l'utilità. fsck filesystem-recovery e, nel peggiore dei casi, perdita di dati.
Tuttavia, sappiamo tutti che molti dispositivi IoT, così come router, termostati e automobili, ora eseguono Linux. Molti di questi dispositivi hanno poca o nessuna interfaccia utente e non c'è modo di spegnerli "in modo pulito". Immagina di avviare un'auto con la batteria scarica quando l'alimentazione alla centralina è assente saltando continuamente su e giù. Com'è possibile che il sistema si avvii senza molto tempo fsckquando finalmente il motore inizia a funzionare? E la risposta è semplice. I dispositivi incorporati si basano sul file system root (abbreviato ro-rootfs (file system root di sola lettura)).
ro-rootfs offrono molti vantaggi meno evidenti dell’autenticità. Un vantaggio è che il malware non può scrivere /usr o /lib, se nessun processo Linux può scrivere lì. Un'altra è che un file system sostanzialmente immutabile è fondamentale per il supporto sul campo dei dispositivi remoti, poiché il personale di supporto si affida a sistemi locali che sono nominalmente identici ai sistemi sul campo. Forse il vantaggio più importante (ma anche il più insidioso) è che ro-rootfs costringe gli sviluppatori a decidere quali oggetti di sistema saranno immutabili in fase di progettazione del sistema. Lavorare con ro-rootfs può essere scomodo e doloroso, poiché le variabili const spesso si trovano nei linguaggi di programmazione, ma i loro vantaggi giustificano facilmente il sovraccarico aggiuntivo.
creazione rootfs La sola lettura richiede uno sforzo aggiuntivo per gli sviluppatori integrati, ed è qui che entra in gioco VFS. Linux richiede che i file siano presenti /var erano scrivibili e, inoltre, molte applicazioni popolari che eseguono sistemi embedded tentano di creare configurazioni dot-files в $HOME. Una soluzione per i file di configurazione nella directory home è solitamente quella di pregenerarli e incorporarli rootfs. Per /var Un approccio possibile è montarlo su una partizione scrivibile separata, mentre / montato in sola lettura. Un'altra alternativa popolare è utilizzare supporti vincolati o sovrapposti.
Supporti collegabili e impilabili, loro utilizzo in contenitori
Esecuzione del comando man mount è il modo migliore per conoscere i montaggi associabili e sovrapponibili, che offrono agli sviluppatori e agli amministratori di sistema la possibilità di creare un file system in un percorso e quindi esporlo alle applicazioni in un altro. Per i sistemi embedded, ciò significa la possibilità di archiviare file in /var su un'unità flash di sola lettura, ma da un percorso di montaggio sovrapposto o collegabile tmpfs в /var durante il caricamento, consentirà alle applicazioni di scrivere note lì (scarabocchio). La prossima volta che attivi le modifiche a /var saranno persi. Un supporto sovrapposto crea un'unione tra tmpfs e il file system sottostante e consente di apportare modifiche apparenti ai file esistenti in ro-tootf mentre una cavalcatura legabile può renderne vuote delle nuove tmpfs cartelle visibili come scrivibili in ro-rootfs modi. Mentre overlayfs questo è quello giusto (proper) tipo di file system in cui è implementato il montaggio associabile .
In base alla descrizione del rivestimento e del supporto collegabile, nessuno se ne stupisce vengono utilizzati attivamente. Vediamo cosa succede quando lo usiamo per eseguire il contenitore utilizzando lo strumento mountsnoop от bcc.
chiamata system-nspawn avvia il contenitore durante l'esecuzione mountsnoop.py.
Vediamo cosa è successo:
Запуск mountsnoop mentre il contenitore si sta "avviando" mostra che il tempo di esecuzione del contenitore dipende fortemente dal montaggio collegato (viene mostrato solo l'inizio dell'output lungo).
Qui systemd-nspawn fornisce i file selezionati in procfs и sysfs host al contenitore come percorsi ad esso rootfs... Oltretutto MS_BIND flag che imposta il montaggio dell'associazione, alcuni altri flag sul montaggio definiscono la relazione tra le modifiche agli spazi dei nomi host e contenitore. Ad esempio, una montatura collegata può ignorare le modifiche a /proc и /sys nel contenitore, oppure nasconderli a seconda della chiamata.
conclusione
Comprendere il funzionamento interno di Linux può sembrare un compito impossibile, dal momento che il kernel stesso contiene un'enorme quantità di codice, lasciando da parte le applicazioni dello spazio utente Linux e le interfacce delle chiamate di sistema nelle librerie C come glibc. Un modo per fare progressi è leggere il codice sorgente di un sottosistema del kernel, con particolare attenzione alla comprensione delle chiamate di sistema e delle intestazioni dello spazio utente, nonché delle principali interfacce interne del kernel, come la tabella file_operations. Le operazioni sui file forniscono il principio "tutto è un file", rendendole particolarmente piacevoli da gestire. File sorgente del kernel C nella directory di livello superiore fs/ presentare un'implementazione di file system virtuali, che costituiscono uno strato wrapper che fornisce una compatibilità ampia e relativamente semplice tra i file system e i dispositivi di archiviazione più diffusi. Il collegamento e il montaggio in sovrapposizione tramite spazi dei nomi Linux è la magia di VFS che rende possibile la creazione di contenitori di sola lettura e filesystem root. Combinato con un esame del codice sorgente, dello strumento principale di eBPF e della sua interfaccia bcc
rendendo l'esplorazione dei nuclei più semplice che mai.
Amici, scrivete, vi è stato utile questo articolo? Forse hai qualche commento o osservazione? E coloro che sono interessati al corso per amministratori Linux sono invitati a parteciparvi , che si svolgerà il 18 aprile.
Fonte: habr.com