SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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.
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.
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.
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.
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.
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-??
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
