É possível saber se meu kernel do Linux é personalizado (ou seja, compilado) em oposição à distribuição?

10

Tomando o exemplo do Ubuntu, podemos dizer se o kernel foi compilado de maneira personalizada e não o que vem com a distribuição?

ubuntu linux-kernel bytefire
fonte
Verifique esta discussão: unix.stackexchange.com/questions/43164/…
nomadrc
2
Bem, só comparação binária com arquivo de pacote ... e ver, se é do kernel original ou se foi alterado ..
kravemir

Respostas:

13

Claro, basta verificar se dpkgsabe sobre isso.

Primeiro verifique a versão do kernel que você está executando.

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

Em seguida, diga dpkgpara procurar o arquivo de imagem do kernel no dpkgbanco de dados.

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

Ou, melhor, use dlocateo dlocatepacote. dlocateprimeiro cria um cache a partir do dpkgbanco de dados e usa isso. Então é rápido.

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

Por fim, verifique se os arquivos Debian contêm este pacote.

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

Caso contrário, é um pacote personalizado. Obviamente, se o dpkg não sabe sobre o arquivo de imagem, seu kernel não faz parte de nenhum pacote, mas foi compilado localmente.

Note que apt pode dizer a diferença entre um pacote no repositório Debian e um compilado localmente com o mesmo nome. Acho que verifica o md5sum do pacote, mas esqueço os detalhes de como isso acontece. Os pacotes binários contêm informações sobre hashes, veja na parte inferior apt-cache show linux-image-3.2.0-4-amd64, por exemplo. por exemplo

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
Por favor, veja meus comentários sobre a resposta do exussum. E se você apenas recompilar o mesmo kernel, com opções diferentes, mas não der outro nome a ele?
terdon
@terdon ver edições.
Faheem Mitha
2
Ah, sim, os hashes devem fazê-lo, inteligente!
terdon
Embora essa abordagem funcione na maioria dos casos, ela não funciona na minha, pois eu tenho um repositório particular para pacotes compilados localmente; portanto, ela aparece como um pacote de fornecedor, mesmo quando eu uso um pacote compilado localmente. é claro que você pode identificar facilmente a diferença, pois os pacotes do fornecedor têm o nome do fornecedor como parte da versão, onde meus pacotes têm o meu nome.
usar o seguinte comando
1
@bytefire apt-cache show ...funciona. Eu vejo que eu digitei errado. Corrigindo agora.
Faheem Mitha
7

Minimamente, uname -rdará a versão kernal, como 3.18.6. No entanto, quando o kernel é compilado, uma string adicional pode ser configurada e anexada a isso, e as distribuições geralmente fazem isso para indicar seu próprio nível de patch (após um traço) e seu sabor, como 3.18.6-32-generic. Essa é uma pista; obviamente, usar sua própria string quando você cria um kernel personalizado pode ser outro.

uname -v dá uma string que por padrão é algo como isto

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

O número é arbitrário no sentido de que é o número de vezes que esse kernel foi construído usando uma árvore de origem específica sem que a árvore seja redefinida - isso pode ser útil quando você está construindo o seu próprio. SMPindica um kernel multitarefa (isto é, não em tempo real) e PREEMPT é outra opção de configuração relacionada ao "modelo de preempção" do agendador. Mas a grande pista aqui é provavelmente a hora em que foi construída. Isso pode ser usado para comparar com o carimbo de data / hora de modificação / mudança no próprio kernel, tendo em mente que pode ser alterado, por exemplo, com touch. Por exemplo, statnesse kernel se parece com isso:

  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: -

O que está praticamente alinhado com Mon Mar 9 13:55:25 EDT 2015.

Cachinhos Dourados
fonte
2

Igual a qualquer outro

sudo apt-cache policy linux-generic

é a versão instalada pelo gerenciador de pacotes e 

uname -r

compare as versões

para mim é 

linux-generic:
  Installed: 3.19.0.15.14
  Candidate: 3.19.0.15.14

e

3.19.0-15-generic

que indicam a mesma versão

exussum
fonte
1
Isso mudará se você recompilar a mesma versão com opções diferentes? Não vejo por que a string da versão mudaria nesse caso.
terdon
Não tenho certeza se 2 com o mesmo nome serão instalados. Eu não tentei. Pessoalmente, quando recompilar com diferentes opções para remover a versão do gerenciador de pacotes para eliminar conflitos
exussum
Eu acho que o mesmo nome seria simplesmente substituído /boot. Meu argumento é que não vejo por que você esperaria que a saída unamefosse alterada se você apenas recompile enquanto altera algumas opções. Nesse caso, eu esperaria isso apt-cachee uname -rretornarei as mesmas informações, apesar de você ter recompilado localmente.
terdon
@terdon A string da versão pode ser personalizada na configuração do kernel, o que é uma boa ideia se você estiver usando a fonte de distribuição.
precisa saber é o seguinte
@ goldilocks sim, eu vi isso na sua resposta e isso faz sentido. No entanto, se eu fosse tolo o suficiente para não ter feito isso e acabei de recompilar o kernel da minha distro alterando algumas opções, as seqüências de versão serão idênticas, certo? Sua sugestão do número de compilações pode ajudar, mas, até onde eu sei, não é o que é sugerido aqui.
terdon
0

Eu diria que a resposta mais geralmente verdadeira é "não, você não pode". Existem vários métodos que podem ajudar em certos casos e estes já foram sugeridos, mas todos parecem não entender como essa situação realmente ocorreu. Na verdade, se você estiver usando um kernel personalizado, ele poderá fazer qualquer coisa, incluindo ocultar sua presença ou parecer um kernel diferente.

Eu ficaria preocupado se você realmente está executando um kernel personalizado e não sabia disso. A única maneira confiável de saber qual kernel está sendo usado é acompanhar cuidadosamente qual kernel você compila e instala.

Se você realmente não tem certeza de qual kernel o sistema está executando ou de quais fontes esse kernel foi construído ou de onde veio, consideraria seriamente reinstalar o sistema operacional a partir de uma boa imagem conhecida e ter mais cuidado no futuro sobre quais kernels você tenta inicializar de ou usar.

Validade
fonte