Tag Archives: kernel

Finding Rootkits By Monitoring For ‘Black Sheep’

Posted on by

Blacksheep compares memory dumps from each monitored system, first creating lists of kernel memory modules that are then sorted and compared, calculating the distance that each list of modules is from the others. The system then compares each byte of a modules’ code with other systems to find differences that could indicate changes inserted by a rootkit. Blacksheep also conduct memory crawling to catch changes to kernel data and checks five different kernel entry points for signs of changes.

via Finding Rootkits By Monitoring For ‘Black Sheep’ – Dark Reading.

EXT4 Data Corruption Bug Hits Stable Linux Kernels

Posted on by

As a warning for those who are normally quick to upgrade to the latest stable vanilla kernel releases, a serious EXT4 data corruption bug worked its way into the stable Linux 3.4, 3.5, and 3.6 kernel series.

via [Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels.

The reason why the problem happens rarely is that the effect of the buggy commit is that if the journal’s starting block is zero, we fail to truncate the journal when we unmount the file system. This can happen if we mount and then unmount the file system fairly quickly, before the log has a chance to wrap. After the first time this has happened, it’s not a disaster, since when we replay the journal, we’ll just replay some extra transactions. But if this happens twice, the oldest valid transaction will still not have gotten updated, but some of the newer transactions from the last mount session will have gotten written by the very latest transacitons, and when we then try to do the extra transaction replays, the metadata blocks can end up getting very scrambled indeed.

Next Linux kernel release supports more ARMs with less code

Posted on by

A new coding effort recently folded into the next version of the Linux kernel may finally resolve the long-running problems associated with Linux on ARM processors. While devices like the Raspberry Pi have shown what can be done with Linux on the low-cost, low-power ARM processor, the burden of developing Linux on the growing number of ARM-derivative processors on the market has been, as Linus Torvalds himself has described it, “a fucking pain in the ass.”

via Next Linux kernel release supports more ARMs with less code | Ars Technica.

Until now, each implementation of ARM by manufacturers has had its own associated kernel code tree, creating a code management nightmare.

Open-Source NVIDIA Driver Approaches Stable State

Posted on by

The Nouveau driver has had a long and challenging journey to get where’s it at today where the developers are now comfortable with the Nouveau driver leaving the Linux kernel’s staging area and thus also fully committing to a stable ABI for their kernel driver (their DRM version is also now marked as v1.0). Nouveau began more than a half-decade ago; I first wrote about the project in 2006 and it wasn’t until 2007 that OpenGL began to sort of work on this free software driver that was started by Stephane Marchesin (he’s no longer directly involved with Nouveau as for a while now he’s been off working for Google on Chrome OS). Nouveau’s journey has been quite interesting and in the past six years has earned itself 450 news posts where I have written about this open-source NVIDIA driver and over 60 featured articles that have included benchmarks or more extensive information on this Linux driver.

via [Phoronix] Open-Source NVIDIA Driver Approaches Stable State.

Linux 3.3: Finally a little good news for bufferbloat

Posted on by

I, Cringely » Blog Archive » Linux 3.3: Finally a little good news for bufferbloat – Cringely on technology.

Bufferbloat, as you’ll recall from my 2011 predictions column, is the result of our misguided attempt to protect streaming applications (now 80 percent of Internet packets) by putting large memory buffers in modems, routers, network cards, and applications. These cascading buffers interfere with each other and with the flow control built into TCP from the very beginning, ultimately breaking that flow control, making things far worse than they’d be if all those buffers simply didn’t exist.

Bufferbloat was named by Jim Gettys of Bell Labs, who has become our chief defender against the scourge, attempting to coordinate what’s become a global response to the problem.

…

What AQM does is monitor the buffer, and signal the end points to slow down any time the buffer starts to fill, either due to that one transfer or competing transfers, by dropping or marking packets.  So the buffer is kept (almost) empty, except when it is handling a burst of traffic. So the steady state latency of the buffer, rather than being the size of the buffer, is set by the size of the bursts in traffic.  The size of the buffer becomes almost irrelevant.

Linux vendors rush to patch privilege escalation flaw after root exploits emerge

Posted on by

According to Carsten Eiram, the chief security specialist at vulnerability research firm Secunia, the flaw was introduced in the Linux kernel code in March 2011 and affects versions 2.6.39 and above. “Any Linux distributions providing these kernel versions should be vulnerable,” Eiram said.

via Linux vendors rush to patch privilege escalation flaw after root exploits emerge – security, secunia, Exploits / vulnerabilities – Malware – Security – Techworld.

Fedora 14 is stuck on 2.6.35 something.  This shouldn’t affect CentOS builds either.  Sometimes it’s beneficial not to upgrade the OS!

scanning for new scsi devices

Posted on by

scanning for new scsi devices.

New devices can be added using echo “scsi add-single-device <h> <b> <t> <l>” > /proc/scsi/scsi where the variables are host, bus (channel), target (scsi id) and lun. The success (or otherwise) of this command can be determined by sending a subsequent cat /proc/scsi/scsi command.

..from the scsi-howto (proc interface) at www.tldp.org – see it for more info.

i have a script “rescan-scsi-bus.sh” here on debian which uses the above method to recheck devices.

HTH ritch.

This was written in 2005. I found the rescan-scsi-bus.sh script on medusa but have no idea which package it came from. It wasn’t on any other Fedora 14 install so it must have come from somewhere. It scans the SCSI bus and finds the drive perfectly well.

What do these SATA errors mean?

Posted on by

For SATA drives, occasional transmission problems are expected even on otherwise pretty healthy systems. No need to worry about it too much unless the problem repeats itself a lot.

via What do these SATA errors mean / kernel 2.6.25.6 (DRDY ERR/ICRC ABRT) | Linux | Kernel.

This error occurred on the drive using the hot swap cage.  I wonder if perhaps the circuitry on the cage is iffy.  The circuit board on that cage is about the simplest board that can be designed — it just maps wires from one pin connector to another — that’s it.

Perhaps the centos install is OK after all.  It’s intermittent which is bad.  Looks like it might pay to use higher quality hot swap cages.  Tomorrow I’ll try another brand and investigate this further.  Here’s another pertinent point.  I’m seeing this exact same error.

> 51/84:f8:47:dc:35/00:03:02:00:00/e0 Emask 0x10 (ATA bus error)
> Jun 11 05:46:23 p34 kernel: [ 1445.288637] ata12.00: status: { DRDY ERR }
> Jun 11 05:46:23 p34 kernel: [ 1445.288639] ata12.00: error: { ICRC ABRT }

That’s your drive reporting that it saw transmission error on the wire.

Finding linux distro release info

Posted on by

Fedora Core: /etc/fedora-release

Red Hat: /etc/redhat-release, /etc/redhat_version (rare)

via release-files.

I got confused between two Centos VMs.  I had thought one Centos VM that I have running DNS was Centos 5.4 and the new one was Centos 5.6.  When I saw that they both used a 2.6.18.* kernel I got confused.  Fedora Core is using 2.6.35 and greater.  This led me to check the distro version upon which I didn’t get it out of uname -a or dmesg.  Searching the intertubes and I got the above answer.  Apparently the VM I thought was 5.4 is really 5.5.

It is interesting that Centos, which tracks RHEL, doesn’t make too many radical changes to the kernel.

Update: It should be noted that I wouldn’t have noticed the kernel versions had I not tried to compile and install my own kernel.