Czy można stwierdzić, czy moje jądro Linuksa jest niestandardowe (tj. Skompilowane) w przeciwieństwie do dystrybucji?

10

Biorąc przykład Ubuntu, czy możemy stwierdzić, czy jądro zostało skompilowane na zamówienie, a nie co zawiera dystrybucję?

ubuntu linux-kernel

— bytefire
źródło

Sprawdź ten wątek: unix.stackexchange.com/questions/43164/…

— nomadrc

2

Cóż, po prostu binarnie porównaj z plikiem pakietu ... i zobacz, czy to oryginalne jądro, czy też zostało zmienione ...

— kravemir

13

Jasne, po prostu sprawdź, czy dpkgo tym wie.

Najpierw sprawdź uruchomioną wersję jądra.

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

Następnie powiedz, dpkgaby szukał pliku obrazu jądra w dpkgbazie danych.

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

Lub, lepiej, użyj dlocatez dlocatepakietu. dlocateNajpierw buduje pamięć podręczną z dpkgbazy danych i korzysta z niej. Więc to jest szybkie.

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

Na koniec sprawdź, czy archiwa Debiana zawierają ten pakiet.

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

Jeśli nie, to jest to pakiet niestandardowy. Oczywiście, jeśli dpkg nie wie o pliku obrazu, to twoje jądro w ogóle nie jest częścią pakietu, ale zostało skompilowane lokalnie.

Zauważ, że apt potrafi odróżnić pakiet w archiwum Debiana od kompilacji lokalnej o tej samej nazwie. Myślę, że sprawdza sumę md5 pakietu, ale nie pamiętam szczegółów, jak to robi. Pakiety binarne zawierają informacje o skrótach, patrz apt-cache show linux-image-3.2.0-4-amd64na przykład na dole . na przykład

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
źródło

1

Proszę zobaczyć moje komentarze do odpowiedzi exussum. Co jeśli po prostu ponownie skompilujesz to samo jądro z różnymi opcjami, ale nie nadasz mu innej nazwy?

— terdon

@terdon zobacz zmiany.

— Faheem Mitha

2

Ach, tak, hasze powinny to zrobić, sprytne!

— terdon

Chociaż takie podejście działa w większości przypadków, nie działa ono w moim, ponieważ mam prywatne repozytorium dla pakietów skompilowanych lokalnie, więc pojawia się jako pakiet dostawcy, nawet jeśli korzystam z pakietu kompilowanego lokalnie. oczywiście możesz łatwo dostrzec różnicę, ponieważ paczki dostawców mają nazwę dostawcy jako część wersji, gdzie moje paczki mają moje imię.

— hildred

1

@bytefire apt-cache show ...działa. Widzę, że się pomyliłem. Poprawianie teraz.

— Faheem Mitha

7

Minimalnie uname -rda wersję jądra, taką jak 3.18.6. Jednak po skompilowaniu jądra można skonfigurować i dołączyć do niego dodatkowy ciąg, a dystrybucje zwykle robią to, aby wskazać własny poziom łatki (po myślniku) i smak, np 3.18.6-32-generic. To jedna wskazówka; oczywiście użycie własnego łańcucha podczas tworzenia niestandardowego jądra może być innym.

uname -v daje ciąg znaków, który domyślnie jest taki

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

Liczba jest dowolna, tzn. Tyle razy jądro zostało zbudowane przy użyciu określonego drzewa źródłowego bez resetowania drzewa - może to być przydatne, gdy budujesz własne. SMPwskazuje jądro wielozadaniowe (tj. nie w czasie rzeczywistym), a PREEMPT jest kolejną opcją konfiguracyjną związaną z „modelem prewencyjnym” programu planującego. Ale najważniejszą wskazówką jest prawdopodobnie czas jej budowy. Można to wykorzystać do dopasowania znacznika czasu modyfikacji / zmiany w samym jądrze, pamiętając, że można to zmienić np touch. Za pomocą . Na przykład statw tym jądrze wygląda następująco:

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

Co jest w zasadzie zgodne z Mon Mar 9 13:55:25 EDT 2015.

— Złotowłosa
źródło

2

Taki sam jak każdy inny

sudo apt-cache policy linux-generic

to wersja zainstalowana przez menedżera pakietów i

uname -r

porównaj wersje

dla mnie to

linux-generic:
  Installed: 3.19.0.15.14
  Candidate: 3.19.0.15.14

i

3.19.0-15-generic

które wskazują tę samą wersję

— exussum
źródło

1

Czy to się zmieni, jeśli ponownie skompilujesz tę samą wersję z różnymi opcjami? Nie rozumiem, dlaczego łańcuch wersji zmieniłby się w takim przypadku.

— terdon

Nie jestem pewien, czy 2 o tej samej nazwie zostaną zainstalowane. Nie próbowałem tego. Osobiście podczas ponownej kompilacji z różnymi opcjami

— usuwam

Domyślam się, że to samo nazwisko zostanie po prostu nadpisane /boot. Chodzi mi o to, że nie rozumiem, dlaczego miałbyś oczekiwać, że wynik unamezmieni się, jeśli po prostu ponownie skompilujesz podczas zmiany niektórych opcji. W takim przypadku oczekiwałbym tego apt-cachei uname -rzwróci te same informacje, mimo że dokonałeś ponownej kompilacji lokalnie.

— terdon

@terdon Ciąg wersji można dostosować w konfiguracji jądra, co jest dobrym pomysłem, jeśli używasz źródła dystrybucji.

— złotowłosa

@ Goldilocks tak, widziałem to w twojej odpowiedzi i to ma sens. Gdybym jednak był na tyle głupi, żeby tego nie zrobić i po prostu ponownie skompilowałem podstawowe jądro mojej dystrybucji, zmieniając kilka opcji, ciągi wersji będą identyczne, prawda? Twoja sugestia liczby kompilacji może pomóc, ale o ile mi wiadomo, nie jest to sugerowane tutaj.

— terdon

0

Powiedziałbym, że najogólniej prawdziwa odpowiedź brzmi „nie, nie możesz”. Istnieją różne metody, które mogą pomóc w niektórych przypadkach, które zostały już zasugerowane, ale wydaje się, że wszystkie tęsknią za faktyczną sytuacją. W rzeczywistości, jeśli używasz niestandardowego jądra, to jądro może zrobić wszystko, w tym ukryć swoją obecność lub wyglądać na inne jądro.

Byłbym zmartwiony, jeśli rzeczywiście używasz niestandardowego jądra i nie wiedziałeś o tym. Jedynym niezawodnym sposobem poznania używanego jądra jest dokładne śledzenie, które jądro skompilujesz i zainstalujesz.

Jeśli naprawdę nie jesteś pewien, z którego jądra działa system lub z jakich źródeł to jądro zostało zbudowane lub skąd ono pochodzi, poważnie zastanowiłbym się nad ponownym zainstalowaniem systemu operacyjnego ze znanego dobrego obrazu i bardziej ostrożnym w przyszłości o tym, które jądra próbujesz uruchomić z lub używać.

— Rzeczywistość
źródło