10

Taking example of Ubuntu, can we tell if the kernel was custom compiled rather than what comes with distro?

bytefire
  • 310
  • 3
  • 11
  • Check this thread: https://unix.stackexchange.com/questions/43164/can-i-detect-if-my-custom-made-kernel-was-built-with-module-support – nomadrc Apr 29 '15 at 16:39
  • 2
    Well, just binary compare with package file... and see, whether it's original kernel or whether it was altered.. – kravemir Apr 29 '15 at 17:25

4 Answers4

13

Sure, just check whether dpkg knows about it.

First check the kernel version you are running.

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

Then tell dpkg to search for the kernel image file in the dpkg database.

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

Or, better, use dlocate from the dlocate package. dlocate first builds a cache from the dpkg database, and uses that. So it is fast.

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

Finally, check that the Debian archives contain this package.

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

If they don't, then it is a custom package. Of course, if dpkg doesn't know about the image file, then your kernel is not part of a package at all, but has been locally compiled.

Note that apt can tell the difference between a package in the Debian archive and a locally compiled one of the same name. I think it checks the md5sum of the package, but I forget the details of how it does that. The binary packages contain information about hashes, see the bottom of apt-cache show linux-image-3.2.0-4-amd64, for example. e.g. 

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
  • 34,649
  • 32
  • 119
  • 183
  • 1
    Please see my comments on exussum's answer. What if you just recomplile the same kernel, with different options, but don't give it another name? – terdon Apr 29 '15 at 18:10
  • @terdon see edits. – Faheem Mitha Apr 29 '15 at 18:13
  • 2
    Ah, yes, the hashes should do it, clever! – terdon Apr 29 '15 at 18:18
  • Although this approach works in most cases, It does not work in mine as I have a private repository for locally compiled packages, so it shows up as a vendor package even when I use a locally compiled package. of course you can spot the difference easily as vendor packages have the vendor name as part of the version, where my packages have my name. – hildred Apr 30 '15 at 03:11
  • @hildred as you point out yourself, the difference between a private repos and the Debian archives is obvious, and the possibility of confusion is approximately nil, so I would say that the method works here too. – Faheem Mitha Apr 30 '15 at 09:11
  • @FaheemMitha, you misunderstood me completely. The only way to tell between the private repo and the vendor repo it that I made specific extra effort with version numbers. If I had not done so there would be no way to tell. – hildred Apr 30 '15 at 15:01
  • @FaheemMitha That's pretty comprehensive, thanks. How do you get the hashes? `apt-cache policy linux-image-3.2.0-4-amd64` doesn't seem to show hashes. – bytefire Apr 30 '15 at 15:13
  • 1
    @bytefire `apt-cache show ...` works. I see I mistyped. Correcting now. – Faheem Mitha Apr 30 '15 at 16:22
  • @hildred `apt-cache policy` and probably other tools show the remote url of the repository, so you could certainly tell the difference between a local repos and the Debian archives. The latter would be a Debian mirror, the former wouldn't. – Faheem Mitha Apr 30 '15 at 16:24
7

Minimally, uname -r will give the kernal version, such as 3.18.6. However, when the kernel is compiled, an additional string can be configured in and attached to that and the distros usually do this to indicate their own patch level (after a dash) and flavour, such as 3.18.6-32-generic. That's one clue; obviously using your own string when you create a custom kernel can be another.

uname -v gives a string which by default is something like this

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

The number is arbitrary in the sense that it is the number of times this kernel was built using a specific source tree without the tree being reset -- this might be useful when you are building your own. SMP indicates a multi-tasking (i.e., not real time) kernel and PREEMPT is another config option related to the scheduler's "preemption model". But the big clue here is probably the time it was built. This could be used to match against the modification/change timestamp on the kernel itself, keeping in mind that can be changed, e.g., with touch. For example, stat on that kernel looks like this:

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

Which is pretty much in line with Mon Mar 9 13:55:25 EDT 2015.

goldilocks
  • 86,451
  • 30
  • 200
  • 258
2

Same as any other

sudo apt-cache policy linux-generic

is the version installed though the package manager and 

uname -r

compare the versions

for me its 

linux-generic:
  Installed: 3.19.0.15.14
  Candidate: 3.19.0.15.14

and

3.19.0-15-generic

which indicate the same version

exussum
  • 3,973
  • 5
  • 19
  • 21
  • 1
    Will that change if you recompile the same version with different options? I don't see why the version string would change in that case. – terdon Apr 29 '15 at 16:46
  • I'm not sure 2 with the same name will install. I have not tried it. Personally when recompiling with different options I remove the version from the package manager to eliminate conflicts – exussum Apr 29 '15 at 17:07
  • I would guess that the same name would simply be overwritten in `/boot`. My point is that I don't see why you would expect the output of `uname` to change if you just recompile while changing some options. In that case, I'd expect that `apt-cache` and `uname -r` will return the same information, despite the fact that you've recompiled locally. – terdon Apr 29 '15 at 17:10
  • @terdon The version string can be customized in the kernel configuration, which is a good idea if you are using the distro source. – goldilocks Apr 29 '15 at 17:12
  • @goldilocks yes, I saw that in your answer and that makes sense. However, if I were silly enough not to have done so, and have just recompiled my distro's stock kernel changing a couple of options, the version strings will be identical, right? Your suggestion of the number of builds might help but, as far as I know, not what is suggested here. – terdon Apr 29 '15 at 17:40
  • I suppose they would, in which case you'd have to differentiate based on `uname -v`. That time should match the mtime of the kernel itself (unless someone has touched it, etc), which is probably a neat method -- I'll edit that in. – goldilocks Apr 29 '15 at 17:47
0

I would say the most generally true answer is "no, you cant". There are various methods which may help in certain cases and these have been suggested already but these all seem to miss how this situation actually came to be. In truth, if you are using a custom kernel, that kernel can do anything, including hiding its presence or appearing to be a different kernel.

I would be worried if you are indeed running a custom kernel and did not know this. The only reliable way of knowing what kernel is being used is carefully keeping track of which kernel's you compile and install.

If you are genuinely not sure what kernel the system is running or what sources this kernel was built from or where it came from I would seriously consider reinstalling the OS from a known good image and being more careful in future about what kernels you try and boot from or use.

Vality
  • 489
  • 3
  • 10