Slack-13 - should I build a custom kernel or not?

Josh000 · 10-09-2009, 08:43 AM

Quote:

Originally Posted by TwinReverb

Well it's not the same logic because modules don't respond over the internet unless that's their design. You can have those services on the machine and not running, which to me sounds like it's the same as compiling as modules but not loading them.

Well, somewhat.

You have to differentiate between local and remote attacks. Someone could use a remote attack, to gain unprivieleged access, and then a local attack targetting a module becomes a lot more serious.

It does not have to do with the module opening up a network socket, at all.

Quote:

If most kernel exploits have not been specific to any drivers and would affect everyone, I don't see how the attack area decreased.

Indeed, it won'T reduce the attack area by much, but it will reduce it.

As an example, look at this recent vulnarability, which only affects people using eCryptfs. This does not appear to be with the default slack kernel, but it certainly is on other distros. With a custom kernel, I am suddenly not vulnerable to this attack.

mudangel · 10-09-2009, 10:49 AM

Quote:

Originally Posted by TwinReverb

Still, it's your machine, have fun 8-)

I don't know why, exactly, but I do think it's fun- I've been working on my laptop's kernel; I couldn't say if it works significantly better, but I've enjoyed the process.

jedi_sith_fears · 10-10-2009, 02:28 AM

Quote:

Originally Posted by ~sHyLoCk~

I didn't notice much improvement with 2.6.31 to be honest. Stock kernel performed well for me as well.

I'll agree too, 2.6.31.1 dosen't seem to be much of an improvement over the stock kernel. Don't know about the 32-bit version, since I haven't tested it yet. With C2D/AMD64 and 32-bit kernel, a bit tweaking with 32-bit Slack 12.2 gave me a speed boost.

slackd · 10-10-2009, 02:59 AM

Quote:

Originally Posted by jedi_sith_fears

I'll agree too, 2.6.31.1 dosen't seem to be much of an improvement over the stock kernel. Don't know about the 32-bit version, since I haven't tested it yet. With C2D/AMD64 and 32-bit kernel, a bit tweaking with 32-bit Slack 12.2 gave me a speed boost.

for me, in slackware 13, building a custom kernel gave me better file transfer rates with lower cpu usage. after compiling the new kernel (without leagcy ata support), my dvd burner was detected as /dev/sr0 rather than /dev/hda.

jedi_sith_fears · 10-11-2009, 04:45 AM

Quote:

Originally Posted by slackd

for me, in slackware 13, building a custom kernel gave me better file transfer rates with lower cpu usage. after compiling the new kernel (without leagcy ata support), my dvd burner was detected as /dev/sr0 rather than /dev/hda.

Thats too obvious.

/dev/hd* for ATA drives
/dev/sd* for SATA drives.

Since you are using ATA drivers from the SCSI/SATA stack as ATA emulation, you are getting the burner as /dev/sr* and not in /dev/hd*.

I have a SATA burner and its detected by default as /dev/sr0.

BrZ · 11-04-2009, 01:26 PM

Check this: CVE-2009-3547

Linux Kernel "fs/pipe.c" NULL Pointer Privilege Escalation Vulnerability
CVE ID : CVE-2009-3547
Rated as : Moderate Risk
Remotely Exploitable : No
Locally Exploitable : Yes
Release Date : 2009-11-??

http://git.kernel.org/?p=linux/kerne...975e0a8cc4466c

TwinReverb · 11-06-2009, 02:26 AM

But this doesn't tell you what uses pipe.c. And given the name, my hunch is that a whole lot of stuff needs it, stuff you can't boot your computer without.

Quote:

Originally Posted by BrZ

Check this: CVE-2009-3547

Linux Kernel "fs/pipe.c" NULL Pointer Privilege Escalation Vulnerability
CVE ID : CVE-2009-3547
Rated as : Moderate Risk
Remotely Exploitable : No
Locally Exploitable : Yes
Release Date : 2009-11-??

http://git.kernel.org/?p=linux/kerne...975e0a8cc4466c

BrZ · 11-06-2009, 05:12 AM

Patched 2.6.31.5 and it is working fine, but with only two days of work it means nothing. If this bug is serious enough and you compile your custom kernel, you are on your own maintaining it.