dkms and corruption of kernel-devel package

[Andre Robatino]

I've noticed that immediately after installing the kernel-devel package, the
mtimes on many of its files fail verification, for example

[root@compaq-pc ~]# rpm -V kernel-devel-3.5.2-1.fc17.x86_64
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/Kconfig
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/Kconfig
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/Kconfig
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/Kconfig.debug
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/boot/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/kernel/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/lib/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/math-emu/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/mm/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/oprofile/Makefile
.......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/arm/Kconfig

and so on. This happens even on old kernels (< 3.5.0) and whether or not dkms is
installed. On kernels >= 3.5.0, with dkms installed, I also noticed that after
installing VirtualBox guest additions for either the host or the guest, the
corresponding /usr/src/kernels/*/System.map file belonging to kernel-devel is
missing. I filed https://www.virtualbox.org/ticket/10847 . My questions are, is
it normal for the files in kernel-devel to fail mtime verification immediately
after install, and does anyone have any idea what's going on with the missing
System.map? One of the vbox developers is of the opinion that it's not a vbox
bug (see https://www.virtualbox.org/ticket/10709#comment:12 ) and that may well
be true, but if so, which Fedora component is likely responsible? kernel? dkms?

[Panu Matilainen]

On 08/21/2012 07:49 PM, Andre Robatino wrote:
>  I've noticed that immediately after installing the kernel-devel
> package, the
>  mtimes on many of its files fail verification, for example
>
>  [root@compaq-pc ~]# rpm -V kernel-devel-3.5.2-1.fc17.x86_64
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/Kconfig
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/Kconfig
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/Kconfig
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/Kconfig.debug
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/boot/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/kernel/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/lib/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/math-emu/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/mm/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/alpha/oprofile/Makefile
>  .......T.    /usr/src/kernels/3.5.2-1.fc17.x86_64/arch/arm/Kconfig
>
>  and so on. This happens even on old kernels (< 3.5.0) and whether or not dkms is
>  installed. On kernels >= 3.5.0, with dkms installed, I also noticed that after
>  installing VirtualBox guest additions for either the host or the guest, the
>  corresponding /usr/src/kernels/*/System.map file belonging to kernel-devel is
>  missing. I filed https://www.virtualbox.org/ticket/10847 . My questions are, is
>  it normal for the files in kernel-devel to fail mtime verification immediately
>  after install, and does anyone have any idea what's going on with the missing
>  System.map? One of the vbox developers is of the opinion that it's not a vbox
>  bug (see https://www.virtualbox.org/ticket/10709#comment:12 ) and that may well
>  be true, but if so, which Fedora component is likely responsible? kernel? dkms? 
Dunno about the System.map (other than I've always relied on the ones in 
/boot), but as for the timestamps, kernel-devel itself causes that as it 
runs hardlink on itself at package post-installation.

	- Panu -

[Josh Boyer]

On Tue, Aug 21, 2012 at 1:01 PM, Panu Matilainen
<pmatilai(a)laiskiainen.org&gt; wrote:
>  Dunno about the System.map (other than I've always relied on the
> ones in
>  /boot), but as for the timestamps, kernel-devel itself causes that as it
>  runs hardlink on itself at package post-installation. 
Right.  There's a bug open for it somewhere.  It's not a priority.
(It's also not clear that a "fix" would be worthwhile.)

josh

[Jason L Tibbitts III]

> >>>> "JB" == Josh Boyer
> <jwboyer(a)gmail.com&gt; writes: 
JB> Right.  There's a bug open for it somewhere.

https://bugzilla.redhat.com/show_bug.cgi?id=826707

 - J<

[Andre Robatino]

Panu Matilainen <pmatilai <at> laiskiainen.org> writes:

>  Dunno about the System.map (other than I've always relied on the
> ones in 
>  /boot), but as for the timestamps, kernel-devel itself causes that as it 
>  runs hardlink on itself at package post-installation. 
Thanks for the info. I wasn't aware there was a copy in a different location,
that's handy. Another question though - the copy in /usr/src/kernels/ is
world-readable and the one in /boot/ isn't, for example

[root@compaq-pc ~]# ls -l /boot/System.map-3.5.2-3.fc17.x86_64
/usr/src/kernels/3.5.2-3.fc17.x86_64/System.map
-rw-------. 1 root root 2468248 Aug 21 15:24 /boot/System.map-3.5.2-3.fc17.x86_64
-rw-r--r--. 1 root root 2468248 Aug 21 15:25
/usr/src/kernels/3.5.2-3.fc17.x86_64/System.map
[root@compaq-pc ~]#

Is there a reason for that?

[John Reiser]

>  the copy in /usr/src/kernels/ is
>  world-readable and the one in /boot/ isn't, for example
>  
>  [root@compaq-pc ~]# ls -l /boot/System.map-3.5.2-3.fc17.x86_64
> /usr/src/kernels/3.5.2-3.fc17.x86_64/System.map
>  -rw-------. 1 root root 2468248 Aug 21 15:24 /boot/System.map-3.5.2-3.fc17.x86_64
>  -rw-r--r--. 1 root root 2468248 Aug 21 15:25
> /usr/src/kernels/3.5.2-3.fc17.x86_64/System.map
>  [root@compaq-pc ~]# 

/boot/System.map is always-present system-specific info which may be useful
to malware for an attack on the running system.
The version in /usr/src/kernels is not present on every machine,
and is more generic: at least a little bit less likely to be correct
for the currently-running kernel.

--

[Josh Boyer]

On Fri, Aug 24, 2012 at 11:34 AM, John Reiser <jreiser(a)bitwagon.com&gt; wrote:
> > the copy in /usr/src/kernels/ is
> > world-readable and the one in /boot/ isn't, for example
> >
> > [root@compaq-pc ~]# ls -l /boot/System.map-3.5.2-3.fc17.x86_64
> /usr/src/kernels/3.5.2-3.fc17.x86_64/System.map
> > -rw-------. 1 root root 2468248 Aug 21 15:24 /boot/System.map-3.5.2-3.fc17.x86_64
> > -rw-r--r--. 1 root root 2468248 Aug 21 15:25
> /usr/src/kernels/3.5.2-3.fc17.x86_64/System.map
> > [root@compaq-pc ~]#
>
>
>  /boot/System.map is always-present system-specific info which may be useful
>  to malware for an attack on the running system. 
No.

>  The version in /usr/src/kernels is not present on every machine,
>  and is more generic: at least a little bit less likely to be correct
>  for the currently-running kernel. 
No.

Unless you've built your own kernel and changed the config, the files
for that particular kernel version are identical.

The kernel-devel copy is 644 because if it was 600 you'd have to build
things against it as root (or change it to 644).  You are correct that
kernel-devel is not installed on every machine though.

josh