Security kernel upgrade

nycace36 · 10-06-2016, 11:29 AM

According to the Slackware Security Advisory from less than 2 months ago http://www.slackware.com/security/vi...ecurity.945021 ::

Quote:

[slackware-security] Linux kernel (SSA:2016-236-03)
New Linux kernel packages are available for Slackware 14.2 and -current to fix a security issue.

and (via ftp://ftp.slackware.com/pub/slackwar.../linux-4.4.19/...)

Quote:

Updated packages for Slackware 14.2:
kernel-firmware-20160823git-noarch-1_slack14.2.txz
kernel-generic-4.4.19-i586-1_slack14.2.txz
kernel-generic-smp-4.4.19_smp-i686-1_slack14.2.txz
kernel-headers-4.4.19_smp-x86-1_slack14.2.txz
kernel-huge-4.4.19-i586-1_slack14.2.txz
kernel-huge-smp-4.4.19_smp-i686-1_slack14.2.txz
kernel-modules-4.4.19-i586-1_slack14.2.txz
kernel-modules-smp-4.4.19_smp-i686-1_slack14.2.txz
kernel-source-4.4.19_smp-noarch-1_slack14.2.txz

Does one have to download and run 'upgradepkg' on all of these for a Slack system that is using, say, a default huge-smp-4.4.14_smp-i686-1_slack14.2 kernel ??
Conversely, Which particular kernel packages can one successfully omit from the above list, for that huge-smp-4.4.14_smp-i686-1_slack14.2 kernel ?? (and see below)

Furthermore,

Quote:

Installation instructions:
+------------------------+

Upgrade the packages as root:
# upgradepkg kernel-*.txz

If you are using an initrd, you'll need to rebuild it.

For a 32-bit SMP machine, use this command:
# /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.19-smp | bash

But what if one originally installed and kept a kernel specifically without an initrd, e.g., huge-smp-4.4.14_smp-i686-1_slack14.2 ??
Does this mean that in order to finish the kernel upgrade process to 4.4.19, it is mandatory to build the appropriate initrd using Pat V's instructions for this ??

Furthermore,

Quote:

If you are using lilo or elilo to boot the machine, you'll need to ensure that the machine is properly prepared before rebooting.

But then how does one "properly prepare the machine before rebooting" using GRUB ??

Even after reviewing LQ threads https://www.linuxquestions.org/quest...-a-4175587817/ , https://www.linuxquestions.org/quest...ot-4175589327/ and https://www.linuxquestions.org/quest...re-4175587521/ , am still a bit lost.

TYIA for good pointers here.

tronayne · 10-06-2016, 11:46 AM

Yes, you should download all of them then run upgradepkg *.t?z in the download directory and, finally, do not forget to run lilo, elilo, or grub before you re boot the system.

I think "properly prepared" means that all the upgrades were downloaded and were in the upgradepkg command.

One thing you may want to do (if you're in a hurry) is to

Code:

sync,sync,sync

before you run lilo (etc.) -- it's not necessary but does make sure that there is nothing left in the system buffers, it's all flushed to disk.

Hope this helps some.

bassmadrigal · 10-06-2016, 11:54 AM

Ideally, you should get all the packages, whether or not you run an initrd, however, initrds are typically only needed on the generic kernels. It has been recommended for quite some time to not use the huge kernel and to use a generic with an initrd, however, many users choose to use huge (I've done it plenty of times, as it is much simpler since you don't need to generate initrds anytime you upgrade). Pat's wording was specific... If you're using an initrd, you'll need to rebuild it. To continue that, if you're not using an initrd, you don't need to build one.

And while the general rule of thumb is to use upgradepkg to upgrade any packages (or slackpkg upgrade-all), I typically recommend using installpkg to install new kernels, then add a new entry in your grub equivalent of /etc/lilo.conf (I've never used grub, so how to do that will need to be left to someone else), leaving the original entry intact. That way, if something happens to go wrong, you can still boot up your old kernel without needing to pull out an installation disc/thumbdrive.

Once you've verified the new kernels are working properly, you can then remove the old ones.

RadicalDreamer · 10-06-2016, 12:16 PM

Just make sure you have a usb drive to boot slackware with if you have any problems. If you use slackpkg upgrade-all it will uninstall the old kernels including modules including nvidia's drivers. I usually upgrade the drivers with the kernel if available.

This is how I make an initrd for generic kernel.
Command:
in /boot/
mkinitrd -c -k 4.4.19 -m ext4

You'll have to find the config in grub to specify the initrd.gz and generic kernel image in grub if you decide to use something other than the huge kernel. If it doesn't find initrd.gz it hangs in boot using the default kernel.

TracyTiger · 10-06-2016, 02:20 PM

Quote:

Originally Posted by tronayne

One thing you may want to do (if you're in a hurry) is to

Code:

sync,sync,sync

before you run lilo (etc.) -- it's not necessary but does make sure that there is nothing left in the system buffers, it's all flushed to disk.

Hi tronayne, My first *nix knowledge was obtained on UNIX systems before Linux was created. From reading your posts I understand your "formative" years were also on UNIX systems.

I only bring this up because you, as an experienced user, are recommending running the sync command three times.

Are multiple executions of the sync command necessary in present day Linux? I remember many years ago multiple executions of sync were recommended because of SunOS limitations at the time. My understanding has been that a single sync will get the job done on a Linux system.

A few items I found on the subject with a few minutes of searching...

A Unix Folklore web page by Chris Siebermann (I don't know who he is).

The man page for sync(8) reads in part (Slackware 14.1) my emphasis ...

Quote:

On Linux, sync is guaranteed only to schedule the dirty blocks for writing; it can actually take a short time before all the blocks are finally written. The reboot(8) and halt(8) commands take this into account by sleeping for a few seconds after calling sync(2).

This page describes sync as found in the fileutils-4.0 package; other versions may differ slightly.

The man page for sync(2) reads in part under BUGS (Slackware 14.1) my emphasis ...

Quote:

According to the standard specification (e.g., POSIX.1-2001), sync() schedules the writes, but may return before the actual writing is done. However, since version 1.3.20 Linux does actually wait. (This still does not guarantee data integrity: modern disks have large caches.)

This excerpt from Linux System Programming agrees with the sync(2) man page.

Quote:

...retyped ...

The standards to not require sync() to wait until all buffers are flushed to disk before returning; ..... Linux however does wait until until all buffers are committed. Therefore a single sync() is sufficient.

I use the sync(8) command after writing to external storage devices before unmounting (if a file system) and disconnecting them.

I use only a single sync command to do the job but I wait another 3 or 4 seconds after the sync command finishes and the shell prompt returns. On externally connected disk drives I pause a little longer and watch for the disk activity light to stop flashing.

I believe the key to successful synchronization is the delay between the sync command returning and disconnecting the device, not the use of multiple sync commands.

Of course executing multiple sync commands won't hurt anything, it just may not be needed.

What is the best practice to assure proper storage device buffer flushing from the command line?

nycace36 · 10-06-2016, 03:51 PM

Quote:

Originally Posted by bassmadrigal

And while the general rule of thumb is to use upgradepkg to upgrade any packages (or slackpkg upgrade-all), I typically recommend using installpkg to install new kernels, then add a new entry in your grub equivalent of /etc/lilo.conf (I've never used grub, so how to do that will need to be left to someone else), leaving the original entry intact. That way, if something happens to go wrong, you can still boot up your old kernel without needing to pull out an installation disc/thumbdrive.

Once you've verified the new kernels are working properly, you can then remove the old ones.

Thanks for all the helpful advice; the kernel upgrade took fine!

1. wget downloaded all the kernel-*.txz's, weeded out all the *x64* downloads, and then ran 'installpg <kernel-*.txz>' thru sudo.
2. Moved out all the non- *huge-smp-4.4.1X-smp files in /boot leaving it as follows

Code:

lrwxrwxrwx 1 root root       37 Oct  3 13:35 README.initrd -> /usr/doc/mkinitrd-1.4.8/README.initrd
lrwxrwxrwx 1 root root       30 Oct  6 11:35 System.map -> System.map-huge-smp-4.4.19-smp
-rw-r--r-- 1 root root  3170515 Jun 24 12:44 System.map-huge-smp-4.4.14-smp
-rw-r--r-- 1 root root  3171959 Aug 22 15:54 System.map-huge-smp-4.4.19-smp
-rw-r--r-- 1 root root      512 Oct  3 13:44 boot.0800
-rw-r--r-- 1 root root      168 Oct  3 13:44 boot_message.txt
-rw-r--r-- 1 root root      426 Apr 21 13:31 coffee.dat
lrwxrwxrwx 1 root root       26 Oct  6 11:35 config -> config-huge-smp-4.4.19-smp
-rw-r--r-- 1 root root   163217 Jun 24 12:44 config-huge-smp-4.4.14-smp
-rw-r--r-- 1 root root   163217 Aug 22 15:54 config-huge-smp-4.4.19-smp
drwxr-xr-x 6 root root     1024 Oct  6 11:55 grub/
-rw-r--r-- 1 root root    22578 Apr 21 13:31 inside.bmp
-rw-r--r-- 1 root root      432 Apr 21 13:31 inside.dat
drwx------ 2 root root    12288 Oct  3 13:15 lost+found/
-rw------- 1 root root   101376 Oct  3 13:44 map
-rw-r--r-- 1 root root     6878 Apr 21 13:31 onlyblue.bmp
-rw-r--r-- 1 root root      424 Apr 21 13:31 onlyblue.dat
-rw-r--r-- 1 root root    14174 Feb 14  2010 slack.bmp
-rw-r--r-- 1 root root    33192 Apr 21 13:31 tuxlogo.bmp
-rw-r--r-- 1 root root      423 Apr 21 13:31 tuxlogo.dat
lrwxrwxrwx 1 root root       27 Oct  6 11:35 vmlinuz -> vmlinuz-huge-smp-4.4.19-smp
-rw-r--r-- 1 root root  7261312 Jun 24 12:44 vmlinuz-huge-smp-4.4.14-smp
-rw-r--r-- 1 root root  7261936 Aug 22 15:54 vmlinuz-huge-smp-4.4.19-smp

(note that I didn't yet move out or delete the *huge-smp-4.4.14-smp files)

3. In GRUB's /boot/grub/grub.cfg file, manually edited the appropriate entry as opposed to using 'sudo update-grub'.
I.e.,
from

Code:

linux /vmlinuz-huge-smp-4.4.14-smp root=/dev/sda5 ro  vt.default_utf8=0 vga = normal

to

Code:

linux /vmlinuz-huge-smp-4.4.19-smp root=/dev/sda5 ro  vt.default_utf8=0 vga = normal

Once the Slackware system is stable for awhile, will go ahead and delete the *huge-smp-4.4.14-smp as suggested, as well as deleting the remaining non-*huge-smp-4.4.19-smp files.

Yeah!

bassmadrigal · 10-06-2016, 06:11 PM

The only change I'd recommend is rather than just deleting those files, I'd recommend removing them using either removepkg or pkgtool. That way, Slackware's package manager can keep up to date of the files on your system

The easiest way would probably be to open up pkgtool (as root) and then scroll down to Remove, then hit the letter k to go to that letter in the list, then just scroll for the kernel stuff and remove the old entries.

STDOUBT · 10-07-2016, 12:55 AM

FWIW, following this,
http://docs.slackware.com/howtos:sla...:systemupgrade
I blacklist all the kernel stuff, and install (using installpkg) only the kernel and the kernel-modules packages.
Still using the original kernel-firmware that shipped with 14.2
Running -current now, I anticipate that maybe I'll run into trouble eventually if the kernel version gets too far ahead of the kernel-firmware version...
I've got all these still installed:
4.4.14-smp
4.4.16-smp
4.4.17-smp
4.4.19-smp
4.4.20-smp
4.4.22-smp
...because I'm lazy. This weekend I'm applying the latest Oct 1st updates, and plan on excluding headers, source, and firmware.
Weeeeeeeee!

tronayne · 10-07-2016, 11:07 AM

Quote:

Originally Posted by TracyTiger;5614790
Are [B

multiple executions[/B] of the sync command necessary in present day Linux? I remember many years ago multiple executions of sync were recommended because of SunOS limitations at the time. My understanding has been that a single sync will get the job done on a Linux system.

Hi, TracyTiger

Probably, yup, don't really need to do that three.

However, I do notice when copying to a flash drive (as an example) that the first sync does the flushing and sometimes the second does too. The third one doesn't do anything and I can safely yank the thing. I've seen the same sort of activity with CD-ROMs and DVDs.

Back in the prehistory of the world (like System 3, SVR4, Solaris) slow drives with multiple platters and maybe 10M, 20M, 50M of storage it was always a Good Idea to flush manually or in a program, shell or binary, just to make sure. Mostly, you might lose a few lines off a log file but it was possible to lose something you really cared about (it's not any more as far as I know)..

I use KronShell exclusively. KornShell retains its history between sessions (don't know if BASH does or not, don't much care). It's real easy to

Code:

r sy

which just does

Code:

sync,sync, sync

out of ~/.sh_history which I define as HISTSIZE=1000 in ~/.profile.

But it really boils down to...I've always done it that way. Initially on the advice of a crusty old fart at Bell Labs and now I'm an old fart and just about as crusty with a fondness for good bourbon. Doesn't make it right or wrong so I keep on doing it. And, it doesn't hurt anything either.

One other thing I've noticed is that when I'm flipping between user accounts, log out from Xfce, log in as another user and startx that there is a delay (sometimes up to 30 seconds or so). So, I sync before I log out then log in and startx and up it pops right quick.

I did teach a course for a while called UNIX/C Program at an extension of Marygrove College in Detroit. It consisted of six 40 hour weeks, each week covering one or two topics, introduction (how to log on, log off, use the editors, utilities), shell programming (KornShell), C programming, advanced C programming, system administration. Excellent materials, a computer running SCO UNIX, multiple terminals for the students (like about 20). At that point, I'd been at it for a few years (I was a Cromemco computers VAR; Cromemco UNIX was BSD for 68030 and 68040 procs) and I learned more teaching than I'd ever been aware of, I knew C, enough to be dangerous with the shell (sh, not ksh), installing drives and all that but teaching that course and keeping ahead of the students taught me a heck of a lot. One of the things learned with SCO and multiple terminals was to sync to make sure that everything really did get written to the disk (which, if I remember correctly, was 140M).

One day in the second week, a student came in with a pack of floppies that contained something called Linux. Everybody took a crack at taking the pack and installing on their home PCs and, boy oh boy, did they have some fun applying what they'd learned in class.

First time I'd ever heard of it and now I won't allow anything else on the property.

Hope this helps some.

bormant · 10-10-2016, 10:03 AM

Quote:

Originally Posted by nycace36

2. Moved out all the non- *huge-smp-4.4.1X-smp files in /boot leaving it as follows
...

3. In GRUB's /boot/grub/grub.cfg file, manually edited the appropriate entry as opposed to using 'sudo update-grub'.
I.e.,
from

Code:

linux /vmlinuz-huge-smp-4.4.14-smp root=/dev/sda5 ro  vt.default_utf8=0 vga = normal

to

Code:

linux /vmlinuz-huge-smp-4.4.19-smp root=/dev/sda5 ro  vt.default_utf8=0 vga = normal

Once the Slackware system is stable for awhile, will go ahead and delete the *huge-smp-4.4.14-smp as suggested, as well as deleting the remaining non-*huge-smp-4.4.19-smp files.

Starting from 14.2 kernel packages contain also unversioned symlink that install/doinst.sh creates:

Code:

( cd boot ; rm -rf vmlinuz-huge )
( cd boot ; ln -sf vmlinuz-huge-4.4.19 vmlinuz-huge )

Code:

( cd boot ; rm -rf vmlinuz-huge-smp )
( cd boot ; ln -sf vmlinuz-huge-smp-4.4.19-smp vmlinuz-huge-smp )

and so on for generic and generic-smp.
So you can place in GRUB's /boot/grub/grub.cfg file

Code:

linux /vmlinuz-huge-smp root=/dev/sda5 ro  vt.default_utf8=0 vga = normal

and don't touch it on kernel upgrades because "installpkg kernel-..." will set the symlink to new kernel image from package.

TracyTiger · 10-11-2016, 09:28 PM

@tronayne - Thanks for the response.

Quote:

One other thing I've noticed is that when I'm flipping between user accounts, log out from Xfce, log in as another user and startx that there is a delay (sometimes up to 30 seconds or so). So, I sync before I log out then log in and startx and up it pops right quick.

Hmmm, that's interesting. One would think that reading the disk cache in RAM would cause the sync command to not make a difference. Perhaps what's really causing the speedup is a side effect of using the sync command and not the flushing of disk buffers.

Quote:

I did teach a course for a while called UNIX/C Program ...
... and I learned more teaching than I'd ever been aware of
... teaching that course and keeping ahead of the students taught me a heck of a lot.

I learned in college that the best way to learn more and to test if I really understood a subject was to volunteer to tutor other students.

Perhaps I haven't hijacked this thread but I feel like I'm using an amateur radio mountain top repeater and we're one of multiple conversations taking place through the repeater. I'll stop now.