È possibile dire se il mio kernel Linux è personalizzato (ovvero compilato) anziché distro?

10

Prendendo esempio da Ubuntu, possiamo dire se il kernel è stato compilato in modo personalizzato piuttosto che cosa viene fornito con la distribuzione?

ubuntu linux-kernel

— bytefire
fonte

Controlla questa discussione: unix.stackexchange.com/questions/43164/…

— nomadrc

2

Bene, basta un confronto binario con il file del pacchetto ... e vedi, se è il kernel originale o se è stato alterato ..

— kravemir,

13

Certo, controlla se ne è a dpkgconoscenza.

Prima controlla la versione del kernel che stai eseguendo.

uname -a
Linux orwell 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

Quindi dire dpkgdi cercare il file immagine del kernel nel dpkgdatabase.

dpkg -S /boot/vmlinuz-3.2.0-4-amd64
linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64

O meglio usare dlocatedal dlocatepacchetto. dlocatecrea prima una cache dal dpkgdatabase e la utilizza. Quindi è veloce.

dlocate /boot/vmlinuz-3.2.0-4-amd64
linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64

Infine, controlla che gli archivi Debian contengano questo pacchetto.

apt-cache policy linux-image-3.2.0-4-amd64

linux-image-3.2.0-4-amd64:
  Installed: 3.2.68-1+deb7u1
  Candidate: 3.2.68-1+deb7u1
  Version table:
 *** 3.2.68-1+deb7u1 0
        500 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.2.65-1 0
        500 http://httpredir.debian.org/debian/ wheezy/main amd64 Packages

In caso contrario, si tratta di un pacchetto personalizzato. Naturalmente, se dpkg non è a conoscenza del file immagine, il kernel non fa parte di alcun pacchetto, ma è stato compilato localmente.

Nota che apt può dire la differenza tra un pacchetto nell'archivio Debian e uno compilato localmente con lo stesso nome. Penso che controlla il md5sum del pacchetto, ma dimentico i dettagli di come lo fa. I pacchetti binari contengono informazioni sugli hash apt-cache show linux-image-3.2.0-4-amd64, ad esempio in fondo. per esempio

Package: linux-image-3.2.0-4-amd64
Source: linux
Version: 3.2.68-1+deb7u1
Installed-Size: 105729
[...]
Size: 23483788
MD5sum: f9736f30f8b68ae79b2747d8a710ce28
SHA1: 64bfde903892801dccd04b52b12316901a02cd96
SHA256: 775814b3eff4a964b593c0bdeaac20587a4e3ddb1257a9d2bfcf1e9d3b9bfd15

— Faheem Mitha
fonte

1

Si prega di vedere i miei commenti sulla risposta di Exussum. E se ricomplessi lo stesso kernel, con opzioni diverse, ma non gli dessi un altro nome?

— terdon

@terdon vedi le modifiche.

— Faheem Mitha,

2

Ah, sì, gli hash dovrebbero farlo, intelligente!

— terdon

Sebbene questo approccio funzioni nella maggior parte dei casi, non funziona nel mio in quanto ho un repository privato per pacchetti compilati localmente, quindi viene visualizzato come pacchetto fornitore anche quando utilizzo un pacchetto compilato localmente. ovviamente puoi individuare facilmente la differenza poiché i pacchetti del fornitore hanno il nome del fornitore come parte della versione, dove i miei pacchetti hanno il mio nome.

— hildred

1

@bytefire apt-cache show ...funziona. Vedo che ho sbagliato a scrivere. Correzione ora.

— Faheem Mitha,

7

Minimamente, uname -rfornirà la versione kernal, come ad esempio 3.18.6. Tuttavia, quando il kernel viene compilato, una stringa aggiuntiva può essere configurata e collegata a quella e le distribuzioni di solito lo fanno per indicare il proprio livello di patch (dopo un trattino) e sapore, come 3.18.6-32-generic. Questo è un indizio; ovviamente usare la propria stringa quando si crea un kernel personalizzato può essere un altro.

uname -v dà una stringa che per impostazione predefinita è qualcosa del genere

#4 SMP PREEMPT Mon Mar 9 13:55:25 EDT 2015

Il numero è arbitrario, nel senso che è il numero di volte che questo kernel è stato creato usando un albero dei sorgenti specifico senza che l'albero sia stato resettato - questo potrebbe essere utile quando si sta costruendo il proprio. SMPindica un kernel multi-tasking (cioè non in tempo reale) e PREEMPT è un'altra opzione di configurazione relativa al "modello di prelazione" dello scheduler. Ma il grande indizio qui è probabilmente il momento in cui è stato costruito. Questo potrebbe essere usato per confrontarsi con il timestamp di modifica / cambiamento sul kernel stesso, tenendo presente che può essere cambiato, ad esempio, con touch. Ad esempio, statsu quel kernel appare così:

  File: ‘3.19-goldilocksSpecial’
  Size: 6858880         Blocks: 13400      IO Block: 4096   regular file
Device: 801h/2049d      Inode: 3156605     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-02-15 15:32:29.000000000 -0500
Modify: 2015-03-03 13:55:21.000000000 -0500
Change: 2015-03-03 14:02:26.767045553 -0500
 Birth: -

Il che è praticamente in linea con Mon Mar 9 13:55:25 EDT 2015.

— goldilocks
fonte

2

Come qualsiasi altro

sudo apt-cache policy linux-generic

è la versione installata tramite il gestore pacchetti e

uname -r

confrontare le versioni

per me è

linux-generic:
  Installed: 3.19.0.15.14
  Candidate: 3.19.0.15.14

e

3.19.0-15-generic

che indicano la stessa versione

— exussum
fonte

1

Questo cambierà se ricompili la stessa versione con opzioni diverse? Non vedo perché la stringa di versione cambierebbe in quel caso.

— terdon

Non sono sicuro che verrà installato 2 con lo stesso nome. Non l'ho provato Personalmente durante la ricompilazione con diverse opzioni rimuovo la versione dal gestore pacchetti per eliminare i conflitti

— esussum

Immagino che lo stesso nome verrebbe semplicemente sovrascritto /boot. Il punto è che non vedo perché ti aspetti che l'output unamecambi se ti ricompili mentre cambi alcune opzioni. In tal caso, me lo aspetto apt-cachee uname -rrestituirò le stesse informazioni, nonostante il fatto che tu abbia ricompilato localmente.

— terdon

@terdon La stringa di versione può essere personalizzata nella configurazione del kernel, il che è una buona idea se si sta usando il sorgente distro.

— Riccioli d'oro,

@goldilocks sì, l'ho visto nella tua risposta e ha senso. Tuttavia, se fossi abbastanza sciocco da non averlo fatto, e avrei appena ricompilato il kernel stock della mia distribuzione cambiando un paio di opzioni, le stringhe di versione saranno identiche, giusto? Il tuo suggerimento sul numero di build potrebbe essere d'aiuto ma, per quanto ne so, non quello che viene suggerito qui.

— terdon

0

Direi che la risposta più generalmente vera è "no, non puoi". Esistono vari metodi che possono aiutare in alcuni casi e questi sono già stati suggeriti, ma tutti sembrano mancare di come si sia effettivamente verificata questa situazione. In verità, se stai usando un kernel personalizzato, quel kernel può fare qualsiasi cosa, incluso nascondere la sua presenza o sembrare un kernel diverso.

Sarei preoccupato se stai effettivamente eseguendo un kernel personalizzato e non lo sapessi. L'unico modo affidabile per sapere quale kernel viene utilizzato è tenere attentamente traccia di quale kernel si compila e si installa.

Se non sei sinceramente sicuro di quale kernel sia in esecuzione il sistema o da quali fonti questo kernel sia stato creato o da dove provenga, prenderei seriamente in considerazione la reinstallazione del sistema operativo da una buona immagine conosciuta e di essere più attento in futuro su quali kernel provi e avvii da o utilizzare.

— Vality
fonte