from http://www.h-online.com/security/news/i ... 81317.html

"...the vulnerability was discovered and remedied back in 2007, but at some point in 2008 kernel developers apparently removed the patch, reintroducing the vulnerability. The older exploit apparently only needed slight modifications to work with the new hole."

Here is a test to see if your system has been exploited:

https://www.ksplice.com/uptrack/cve-2010-3081.ssi.xhtml

James

Most Linode users should be running 32-bit distros (64-bit can have some performance improvements in certain instances, but for the most part just wastes a ton of extra memory), so hopefully few will be affected.

I'm on 64-bit myself, mostly for relentless future-proofing but I think I've also seen in places that databases do well with 64-bit (maybe, dunno).

Anyway, I'm running a Debian kernel (the lenny-backports amd64 one) via pv-grub, and updated to the new kernel painlessly as soon as Debian pumped it out a couple of days ago.

I feel my decision to track Debian stock kernels is a bit justified now. Not that Linode won't do a great job of patching this - but with Debian I get the security emails and the cron-apt emails and it makes it easy to stay on top of things like this instead of the "check linode.com/kernel/ periodically". An email notification system from Linode (does one exist that I don't know about?) would be a good move I reckon.

Interesting- all of my home boxes run Debian, though only one is 64 bit. For that (this) one the test gives:
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)

$$$ Kernel release: 2.6.32-bpo.5-amd64
!!! Could not find symbol: per_cpu__current_task

A symbol required by the published exploit for CVE-2010-3081 is not
provided by your kernel. The exploit would not work on your system.

_________________
--
Chris Bryant

Linode Kernel RSS Feed: http://www.linode.com/kernels/rss.xml

FWIW, distro provided xen kernels suck, in my experience. More trouble than they're worth. We spend a large amount of time making sure our kernels are well maintained and stable. You really want to be using ours...

-Chris

Would you be willing to tell me why? I am not using xen kernel since I go Gentoo (Hardened) way and thus I am more interested in specific config options. As far as I noticed there are not that many Xen specific options that could be screwed.

Hmm, maybe is somewhere around some explanation on compiling custom kernel? From my point of view, compiling kernel for Linode is fun because it can get very subtle since we can disable the most devices and it's not too complex. Yet there may be some hidden issues I didn't notice.

I'm not using a Xen kernel, I'm using a regular Debian kernel and relying on its mainline pv_ops support.

Would you still make the same claim about that?



I was under the impression you guys pretty much use kernel.org stock (for pv_ops kernels, that is) with a bunch of config options that you've tailored through experience or to fix specific Linode issues.

I know that Debian would make the argument that they also spend a lot of time making their kernels well-maintained and stable. Linode, it seems, has jumped from 2.6.32, to 2.6.34, back to 2.6.32, to 2.6.35 based kernels in the space of a few months - I know you must have good reasons but I can't see what is "stable" (unchanging) about jumping between such completely different code bases - such as this move from 2.6.32 to 2.6.35 to fix a single vulnerability - rather than maintain a stable 2.6.32 tree or something.

(unless we've misunderstood each other and you were referring to your 2.6.18 Xen-based kernels rather than pv_ops)

I'd be really interested in more information about how you make your kernels though. If you apply any patches, etc - what makes them different to stock kernels from distros, etc. The technical details that can help me make a decision.

I run 64 bit centos with 64 bit versions of cherokee, mysql, postfix, php etc and my main site is noticeable faster so it does make a difference in some cases. Large complex sql query performance I think is the main boost from going 64 bit.

At idle, I use around 70mb going up to 220mb when it gets busy, so no problem fitting that into a linode 512.

The only speed benefits I've seen in benchmarks on a Linode are database speeds, and the memory usage is a decent chunk higher on 64-bit. So for users that are not doing really heavy database work, you're probably better off with the extra RAM rather than the extra DB performance.

im running 32bit b/c as said, 64bit tends to use a little more ram.
linode boxes are quite limited on ram so i want to free up as much as i can. also we are not using more than 4gb of ram per vps so another reason 64bit is not necessary.

there may be other uses for 64bit but i am fine with 32bit for now on a server.

(coming from a person who has been using 64bit operating systems since xp 64)

Given that the smallest linode is 512mb and my ram usage on a full 64 bit system is less than half that, I'll take the database performance boost any day. Even if performance was only boosted by 1% there's really no downside to going 64 bit (at least in my case) as I'm still nowhere near maxing out the ram.

The enhanced database speed is definitely a plus (again in my particular case, mileage may vary for others)

Certainly, if database performance is important to you, then that decision is perfectly justified. But (as a general reminder to everyone, not specifically you) remember, any unused RAM will go toward disk caching (among other things). Performance can suffer if you run with a low amount of free RAM, and having more free RAM is always better than less free RAM.