Kernel Traffic #257 For 6 Apr 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1911 posts in 9942K.

There were 528 different contributors. 259 posted more than once. 176 posted last week too.

The top posters of the week were:

1. Status Of Lan Media's WAN Card Driver In 2.6

26 Feb 2004 - 11 Mar 2004 (18 posts) Archive Link: "What happened to LAN Media Corporation?"

Topics: MAINTAINERS File

People: Daniel EggerAdrian BunkMarcelo TosattiSam RavnborgMuli Ben-YehudaDave JonesHorst von Brand

Adrian Bunk noticed that Lan Media's WAN card driver was listed in the MAINTAINERS file as being maintained by Andrew Stanley-Jones of that company; but that the Lan Media website, http://www.lanmedia.com/, was listed as being for sale. He asked what was up, and Dave Jones queries Google, coming up with an acquisition notice by SBE (http://www.sbei.net/archive/prs/2000/071400.htm) as the first hit. Daniel Egger added that after the acquisition:

the first cool action they placed on the market was to substitute all occurrences of LMC in the driver by SBE and make some other incompatible changes to make sure that the old tools wouldn't work with the "new" driver and vice versa. Surprisingly the kernel maintainers did not like this very much so the drivers in the latest kernels are somewhat old and conflicting with the "real" drivers.

What's more, their driver version 3.2 doesn't compile with 2.4.21 and up, so unless they've eventually released their highquality patch/driver/tool/utilities/extras + telnet and more bundle in version 4.0 version which will probably only work up to 2.4.24 anyway (due to the latest HDLC changes), one has to stick to an old version of the driver, which works somewhat but given the extraordinary code quality I would be very surprised if that's a synonym for a nice uptime.

There's something about WAN card manufacturers that seems to say: If you hate us for the sad driver quality, check back with our competition and then come back later...

Adrian asked if, in this case, the MAINTAINERS entry could be removed, and Daniel replied, "This one for sure. The same is probably sensible for the drivers, too. It's just too confusing to have several versions of the driver floating around which need different tools. And since the manufacturer propagates their own version, the linux one should go..." He said he'd post a patch for this soon. Adrian said that removing a driver from a stable kernel series didn't seem like a great idea, though he agreed the MAINTAINERS entry should definitely go. Sam Ravnborg suggested just marking the thing as unmaintained, instead of gutting the entry entirely, but Adrian replied:

In 2.6.4-rc1-mm2, there's exactly one entry marked "Unmaintained" (PCMCIA SUBSYSTEM) and there are very few marked "Orphan".

I don't have a strong opinion on this, but my impresion was that usually unmaintained device drivers are not listed in MAINTAINERS.

Elsewhere, Marcelo Tosatti also thought it would be proper to mark the driver as unmaintained, and Horst von Brand agreed. Hideaki Yoshifuji replied that typically, "Orphan" or "Obsolete" would be used instead of "Unmaintained". Muli Ben-Yehuda suggested adding the "Unmaintained" possibility to the list of possible states for a given driver, but Hideaki felt thta "Orphan" was the proper and traditional term.

The thread ended inconclusively.

2. Status Of kgdb_serial And Run-Time Selection Of KGDB Communication Channels

2 Mar 2004 - 11 Mar 2004 (37 posts) Archive Link: "[PATCH] Kill kgdb_serial"

Topics: Networking

People: Tom RiniGeorge AnzingerPavel MachekAndrew Morton

Tom Rini said, "The following interdiff kills kgdb_serial in favor of function names. This only adds a weak function for kgdb_flush_io, and documents when it would need to be provided." George Anzinger remarked, "It looks like you are also dumping any notion of building a kernel that can choose which method of communication to use for kgdb at run time. Is this so?" Tom replied, "Yes, as this is how Andrew suggested we do it. It becomes quite ugly if you try and allow for any 2 of 3 methods." Pavel Machek objected, "I do not think that having kgdb_serial is so ugly. Are there any other uglyness associated with that?" Tom gave a link to a February posting (http://lkml.org/lkml/2004/2/11/224) where the issue had been discussed, in which Andrew Morton had said, "I don't think runtime selection is very important, personally. You tend to get things set up with a serial cable or ethernet and just leave it that way. Given that you need to recompile the kernel anyway, I'd say that Kconfig-time selection is acceptable." Pavel said that this only showed that Andrew didn't care very much. He went on, "having both serial and ethernet support *is* good idea after all... I have few machines here, some of them do not have serial, and some of them do not have supported ethernet. It would be nice to use same kernel on all of them. Also distribution wants to have "debugging kernel", but does _not_ want to have 10 of them." After some discussion, Tom decided to give up on killing kgdb_serial, and there was some implementation discussion on how to do things cleanly.

3. udev 021 Released; Status Of Module Loading And Unloading

2 Mar 2004 - 13 Mar 2004 (38 posts) Archive Link: "[ANNOUNCE] udev 021 release"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Networking, USB, Version Control

People: Greg KHMichael WeiserAlex GoddardMarco d'Itri

Greg KH said:

I've released the 021 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz)

(Yes, there was no 020 release announcement, that tarball had a number of build issues that prevented rpms from being generated, hence the need for a 021 release. A certain new Ximian/SuSE/Novell employee owes me some beer now that he broke the build and I had to fix it...)

rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.i386.rpm (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.src.rpm (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.src.rpm)

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)

I think udev is pretty much mature now. The TODO list is pretty much empty, and I've integrated in all of the assorted patches that the different distros were using. If there's anything missing from udev, or any patches that I've missed, please let me and the people at the linux-hotplug-devel mailing list know about it.

Major changes from the 019 version:

Thanks to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

He replied to himself a few minutes later, to add:

Two other things about this release that Kay just reminded me about:

And another one I just remembered:

Michael Weiser said, regarding the ability to set permissions for the currently logged in user, "Yay, just the other day I thought that might be a nice feature in concert with RedHat's/Fedora's pam_console module. Am I right in assuming that the current utmp based code will give the file to the user that most recently logged into the local console? This could cause some confusion with the pam_console-method which gives files to the user that logged in *first* on a local console." Greg wasn't sure of the answer to this, and asked Michael to test it out and report back; Michael did so, and reported:

It's even worse. The user logged into the lowest-numbered console will get owner of the newly created file when using $local.

So if I log into tty2 and plug in my USB stick I will be owner of /dev/sda1. If another guy comes along, logs into tty1, unplugs my USB stick and replugs it, he'll be owner of /dev/sda1. But if I log out now, re-login on tty2 and replug the stick again, I won't get the owner of /dev/sda1 but the other guy again. This will certainly break things - at least on Fedora Core 1. Maybe it's different with other distributions/glibc/utmp variants/versions.

Greg replied:

Ick, well you are describing a pretty pathalogical situation. I suspect for 99.9% of the users who would use this option, it will work just fine, as they only have 1 user on the system at a time.

So, if you have multiple users on the physical system, then don't use $local :)

Feel free to send a update to the documentation that illustrates this limitation of the feature.

Elsewhere, in the course of discussion, some question of driver loading and unloading came up; to which Greg said:

the kernel is changing models from one which automatically loaded modules when userspace tried to access the device, to one where the proper modules are loaded when the hardware is found.

Note that this is a much more sane model due to removable devices, and instances of multiple types of the same kind of devices in the same system.

So no, udev is not going to handle this "issue" except in the case of removable devices and their partitions. Which is already working in udev today.

To the outcry that module unloading was a really great feature, Alex Goddard said, "See past linux-kernel threads on how problematic module unloading is (and how insanely hard it'd be to fix those problems). You really shouldn't be using rmmod unless you're a developer as it is." And Greg added, "rmmod -a has not been a wise thing to do since 2.2 came out. It can easily take down a working box..."

Close by, Marco d'Itri objected, "This does not solve the problem of drivers which do not have matching hardware, like PPP and loop device. I do not mind unconditionally loading these modules at boot, but there has to be a way to recognize them: I do not think it is acceptable to load *all* modules available on the system (what is the point of having a modular kernel then?)." Greg said, "Then have your "use the loop device" or "use the ppp device" load the module before it is used. Or manually create the dev node and hope that kmod and its aliases work..." But Michael said, "AFAICS both require root privileges and the latter will break with dynamic device numbers issued by the kernel. The previous model enabled normal users to have the kernel adjust to their current requirements dynamically without the need of being root." There was no reply.

4. OpenIB InfiniBand Driver; Some Intellectual Property Encumberance

5 Mar 2004 - 13 Mar 2004 (5 posts) Archive Link: "ANNOUCE: OpenIB InfiniBand software"

Topics: BSD, Device Mapper, Disks: SCSI, FS: sysfs, Ioctls, Microsoft, PCI, Virtual Memory

People: Roland Dreier

Roland Dreier said:

OPENIB.ORG INFINIBAND DRIVERS RELEASE -- 2004-03-05

We are proud to announce the initial availability of the OpenIB.org InfiniBand stack. This is a fully open source (See the section on SDP intellectual property for some important information, though.) InfiniBand stack that includes a low-level driver for Mellanox HCA hardware, a midlayer, and a number of useful upper-layer protocols including IP-over-InfiniBand, SCSI RDMA Protocol, Sockets Direct Protocol, uDAPL and MPI. In addition userspace utilities are available, including the OpenSM subnet manager.

An initial drop of this source is available from <http://openib.org>. Additional protocols and further enhancements will be added in upcoming releases. In the next few days, we will also be bringing up mailing lists, source code control, and so on.

We look forward to working with the entire Linux community to continue to develop these drivers.

TODO

We are fully aware that our code is far from being acceptable for inclusion in the Linux kernel, and we are very committed to doing the hard work required to clean up the source. We believe that in addition to the benefits of being in the standard kernel, we will find huge improvements in the quality, performance and robustness of our drivers.

As a starting point, here is a list of some of the tasks we believe must be completed before these drivers can be seriously considered for inclusion in the kernel. We would welcome any suggestions of tasks that we have forgotten. Of course patches would be even better!

SDP intellectual property

Microsoft believes that they own certain intellectual property relating to the Sockets Direct Protocol (SDP) (http://www.microsoft.com/mscorp/ip/standards/) . Therefore, we are including the following disclaimer required by Microsoft's license in SDP source that relates to the implementation of the protocol:

"This source code may incorporate intellectual property owned by Microsoft Corporation. Our provision of this source code does not include any licenses or any other rights to you under any Microsoft intellectual property. If you would like a license from Microsoft (e.g., to rebrand, redistribute), you need to contact Microsoft directly."

We realize that this is incompatible with open source licensing, and we are working to find a more satisfactory solution, but for the time being we are forced to comply with Microsoft's license.

Please make sure you have fully understood the implications of Microsoft's claims before you redistribute any of the SDP source that contains the above disclaimer.

The next day he replied to himself:

Several people have requested that we split the possibly-encumbered SDP code into a separate package so that they don't have to download it to get the free code. To allow that, I have split the kernel code into two packages:

infiniband-kernel-2004-03-05.tar.bz2
infiniband-kernel-sdp-2004-03-05.tar.bz2

If you wish to build SDP, you will need to download both packages and move the SDP files into the appropriate place in the tree. For all other protocols, only the first package (containing only pure dual GPL/BSD code) is required.

The new snapshot is available now from <http://openib.org/downloads>. (It also contains a few fixes and code cleanups as compared to the 2004-02-26 drop)

5. Linux 2.6.4-rc2-mm1 Released

7 Mar 2004 - 10 Mar 2004 (30 posts) Archive Link: "2.6.4-rc2-mm1"

Topics: Device Mapper, Disks: IDE, FS: ext3, Kernel Release Announcement, User-Mode Linux

People: Andrew Morton

Andrew Morton announced Linux 2.6.4-rc2-mm1, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4-rc2/2.6.4-rc2-mm1/

6. LVM2 Benchmarking Under 2.6

8 Mar 2004 - 16 Mar 2004 (9 posts) Archive Link: "lvm2 performance data with linux-2.6"

Topics: Disk Arrays: LVM, FS: ext2

People: Mark WongMiquel van SmoorenburgBill Davidsen

Mark Wong said:

I've started collecting various data (including oprofile) using our DBT-2 (OLTP) workload with lvm2 on linux 2.6.2 and 2.6.3 on ia32 and ia64 platforms:

http://developer.osdl.org/markw/lvm2/

So far I've only varied the stripe width with lvm, from 8 KB to 512 KB, for PostgreSQL that is using 8 KB sized blocks with ext2. It appears that a stripe width of 16 KB through 128KB on the ia64 system gives the best throughput for the DBT-2 workload on a volume that should be doing mostly sequential writes.

I'm going to run through more tests varying the block size that PostgreSQL uses, but I wanted to share what I had so far in case there were other suggestions or recommendations.

Miquel van Smoorenburg suggested, "For write-heavy loads, you might want to see if 2.6.4-rc2-mm1 makes any difference. It fixes a case where both pdflush and a writing process itself would queue writes to an LVM device, resulting in less than optimal I/O ordering for some cases. The fix will probably be in 2.6.4 proper as well."

Bill Davidsen also said to Mark:

Here's one thought: look at the i/o rates on individual drives using each stripe size. You *might* see that one size does far fewer seeks than others, which is a secondary thing to optimize after throughput IMHO.

If you don't have a tool for this I can send you the latest diorate which does stuff like this, io rate perdrive or per partition, something I occasionally find revealing.

Mark said he'd been using 'iostat -x' so far, and would definitely like to see the diorate script. Chris Croswhite asked if it were available to all, and Bill replied, "I stuck it on the page I use to avoid beating my fractional T1 to death. http://pages.prodigy.net/davidsen/diorate.pl. Enjoy, any misfeatures please feed back to me."

7. New Intel PRO/Wireless 2100 802.11b Driver

9 Mar 2004 - 11 Mar 2004 (23 posts) Archive Link: "[Announce] Intel PRO/Wireless 2100 802.11b driver"

People: James KetrenosDax KelsonArjan van de VenTimothy Miller

James Ketrenos of Intel, said:

I am pleased to announce the launch of an open source development project for the Intel PRO/Wireless 2100 miniPCI network adapter. The project has been created and is hosted at http://ipw2100.sf.net.

The driver, as it currently stands, is able to associate and communicate in Infrastructure mode. Support for both 2.4 and 2.6 is available. We are releasing this driver now as "early beta" code to get feedback and help in the development, so expect bugs (and please report them)! Of course Intel will continue the effort (as part of this Open Source project). We are planning to add support of all key wireless features (adhoc, WEP, etc) over the next few months, quicker with help from others in the community.

NOTE: Let me reiterate -- this driver is in active development. Features and capabilities available on other operating systems have not all been implemented at this time. This includes wireless features (adhoc, wep) as well as performance and power savings.

I look forward to working with the community to improve and enhance the driver.

So if you have an Intel wireless 802.11b miniPCI network adapter in your laptop... download the bits, give it a whirl, and let me know how it goes. Please also let us know if you encounter any problems that may be related to specific distributions.

Later, he added that Intel had set up a mailing list, at http://lists.sourceforge.net/lists/listinfo/ipw2100-devel.

Arjan van de Ven, Timothy Miller, Dax Kelson and others were very happy to see this. Dax also said:

I took a look at the website and see the GPL driver and the closed firmware.

Is it really *firmware*, in that it loads and executes purely within the Intel PRO/Wireless 2100 itself and not in the linux kernel on the main CPU? If so, bravo!

Does a similar effort exist for the upcoming Sonoma 802.11a/b/g component? Will Linux support be available for Sonoma at launch?

Regarding the firmware question, James confirmed, "Yes, it is really firmware. It is loaded from disk as a block of data and passed to the card. The system CPU doesn't execute anything out of the firmware, nor does the firmware know anything about the kernel." And regarding the upcoming Sonoma 802.11a/b/g, he added, "It is our intention to support a/b/g WLAN with a driver for Linux, but details are being worked out so we have no dates or commitment at this time."

8. Status Of Support For Intel's ICC Compiler

9 Mar 2004 - 12 Mar 2004 (12 posts) Archive Link: "Kernel 2.6.3 patch for Intel Compiler 8.0"

People: Ingo Kubbilun

Ingo Kubbilun said, "please have a look at http://www.pyrillion.org/linuxkernelpatch.html for a working 2.6.3 patch to compile the kernel with Intel Compiler 8.0 for Linux." Norberto Bensa asked how the speed of a kernel compiled with that compiler compared with one compiled with GCC, and Ingo replied:

I used the patch to compile two identical kernels with gcc 3.3.3 and icc 8.0 with oprofile support built in.

The optimization switches were chosen quite conservative, i.e. "-O2 -Ob1", no IPO, and of course: no MMX, SSE, and SSE2 stuff inside the kernel (thus disabling Intel's great vectorizer).

Profiling: lmbench ran ten times but time measurements were taken from oprofile (on Pentium 4, GLOBAL_POWER_EVENTS in kernel space only, counter overflow: 3.000).

Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.

Thus, take the kernel patch as a good basis for modifying the compiler switches and other things to get more performance gains. As I know, a lot of people are looking for a patch.

Please check the patch file; you have to modify a lot of things in 2.6.3 to create a quite stable working version of the kernel. The patch is not just about changing some minor Makefile things...

9. Block Device Hotplugging Improvements

10 Mar 2004 - 14 Mar 2004 (31 posts) Archive Link: "[PATCH] backing dev unplugging"

Topics: Device Mapper, Hot-Plugging

People: Jens AxboeAndrew Morton

Jens Axboe said:

Here's a first cut at killing global plugging of block devices to reduce the nasty contention blk_plug_lock caused. This introduceds per-queue plugging, controlled by the backing_dev_info. Observations:

Patch is against 2.6.4-rc2-mm1.

Various folks liked this, and Andrew Morton said, "This is such an improvement over what we have now it isn't funny."

10. Linux 2.6.4 Released

10 Mar 2004 - 12 Mar 2004 (4 posts) Archive Link: "Linux 2.6.4"

Topics: Kernel Release Announcement, Version Control

People: Linus TorvaldsJan De LuyckPavel Machek

Linus Torvalds announced 2.6.4, saying:

A few small fixes since -rc3, most notably an OHCI bug that would corrupt memory and seems to have been the reason for the "Bad page flags" bug at least on ppc64 (it's not been reported on x86, as far as I know, but I don't see why the corruption couldn't have happened there too).

The full changelog from 2.6.3 is on the ftp-sites along with the patches and tar-balls, and the BK trees have been updated.

Jan De Luyck asked, "The new -mregparm=3 support, how likely is it to totally break one's system?" Pavel Machek replied, "There were some problems with that, but they should be fixed. If you are using binary-only drivers, stay away from that."

11. Linux 2.6.4-mm1 Released

10 Mar 2004 - 15 Mar 2004 (67 posts) Archive Link: "2.6.4-mm1"

Topics: Big O Notation, FS: XFS, FS: ext2, Hot-Plugging, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced 2.6.4-mm1, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/2.6.4-mm1/

12. Lightweight System Call Auditing

11 Mar 2004 - 17 Mar 2004 (9 posts) Archive Link: "[PATCH] Light-weight Auditing Framework"

People: Rik FaithStephen Smalley

Rik Faith said:

Below is a patch against 2.6.4 that provides a low-overhead system-call auditing framework for Linux that is usable by LSM components (e.g., SELinux). This is an update of the patch discussed in this thread:
http://marc.theaimsgroup.com/?t=107815888100001&r=1&w=2

In brief, it provides for netlink-based logging of audit records that have been generated in other parts of the kernel (e.g., SELinux) as well as the ability to audit system calls, either independently (using simple filtering) or as a compliment to the audit record that another part of the kernel generated.

The main goals were to provide system call auditing with 1) as low overhead as possible, and 2) without duplicating functionality that is already provided by SELinux (and/or other security infrastructures). This framework will work "stand-alone", but is not designed to provide, e.g., CAPP functionality without another security component in place.

This updated patch includes changes from feedback I have received, including the ability to compile without CONFIG_NET (and better use of tabs, so use -w if you diff against the older patch).

Please see http://people.redhat.com/faith/audit/ for an early example user-space client (auditd-0.4.tar.gz) and instructions on how to try it.

My future intentions at the kernel level include improving filtering (e.g., syscall personality/exit codes) and syscall support for more architectures. First, though, I'm going to work on documentation, a (real) audit daemon, and patches for other user-space tools so that people can play with the framework and understand how it can be used with and without SELinux.

Stephen Smalley remarked, "FYI, I have no objection to the changes in this patch to the SELinux module; we would be glad to have SELinux use this auditing framework if it is accepted into the mainline kernel. I suppose we can separately submit a patch to remove the avc_ratelimit code from the SELinux avc, as that should be handled by the audit framework itself."

13. Fan Driver Expanded Coverage And New Name

11 Mar 2004 - 15 Mar 2004 (4 posts) Archive Link: "[PATCH] therm_adt7467 update"

Topics: Version Control

People: Colin LeroyBenjamin Herrenschmidt

Colin Leroy said, "the fan driver I wrote for adt746x looks like it only handles the adt7467 chip found in iBooks G4; but it also handles the adt7460 chip found in the Powerbook G4 Alu. Here's a patch that renames the file to therm_adt746x.c and updates Kconfig and Makefile." Benjamin Herrenschmidt replied, "Ok, I'll look into getting that upstream. Renaming things is a bit nasty (makes big patch for little changes) unless Linus does directly a "bk mv" in his tree.."

14. Status Of Rootkit Attacks Against 2.6

11 Mar 2004 - 13 Mar 2004 (17 posts) Archive Link: "LKM rootkits in 2.6.x"

Topics: Security

People: Pete SmithHorst von BrandDave JonesJirka KosinaDax KelsonValdis KletnieksChristophe Saout

Pete Smith asked, "Any thoughts on the future of LKM rootkits in the 2.6 kernel branch ? In the last few years I've become quite interested in them (from a defensive point of view), but with the 2.6 kernel no longer exporting the syscall table, intercepting system calls would appear to be a non-starter now." Horst von Brand replied, "If you get to load a module, you are in-kernel. Once there, you can either use what you know are the offsets for $distro-$version-$arch kernel and be in business as usual, or fool around on your own. Harder than before, yes. Impossible, by no means." Valdis Kletnieks also gave a pointer to a 2.6 port of the adore-ng rootkit (http://stealth.7350.org/rootkits/adore-ng-0.41.tgz) that had been mentioned by an anonymous poster on BugTraq. The poster had said, "All of the stuff you know from earlier kernel 2.4 versions such as socket-, process- and file-hiding, syslog- and [uw]tmp filtering has been ported. Additionally since version 0.32 a buffer overflow has been fixed (doh!) which could lead to crashes when a lot of network connections exist." Paul Rolland took a look at this, and noticed that the rootkit no longer used the system call layer, but did its work via the Virtual Filesystem. Paul suggested hiding the VFS now, as well. Elsewhere, Dave Jones also pointed out that rootkit authors could also "start doing what binary-only driver vendors have been doing for months.. If the table isn't exported, they find a symbol that is exported, and grovel around in memory near there until they find something that looks like it, and patch accordingly." Jirka Kosina replied, "Why bother .. just find any symbol (function name) which is exported to modules and also being frequently called somehow indirectly from userland (VFS layer functions, vm functions, ...) and use this function as an open-backdoor spell. It is easy to patch existing rootkits this way."

Christophe Saout asked if it was really true that binary driver vendors were using the method Dave described, and Dax Kelson asked which vendors and modules did this. Dave replied, "Most recent one I saw was some 'antivirus' filescanning module. The name escapes me. It was mentioned on l-k at the time. It wasn't the first by any means however. This trick has been used since vendors stopped exporting sys_call_table."

15. Hotplug Scripts Update Released

11 Mar 2004 (1 post) Archive Link: "[ANNOUNCE] 2004-03-11 release of hotplug scripts"

Topics: Hot-Plugging

People: Greg KH

Greg KH said:

I've just packaged up the latest Linux hotplug scripts into a release, which can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.gz (http://www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.gz) or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.bz2 (http://www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.bz2)

This is a snapshot of the recent development in the scripts, and should be used by anyone who has reported a bug or sent me a patch against the last release, to check if your fix is in or not.

If I have missed any changes, please let me know and send the patch to me and the linux-hotplug-devel mailing list. I'll collect them all and make a "official" release afterwards.

Sorry for delaying so long since the last hotplug release.

16. UML Updated To Support 2.6.4

11 Mar 2004 - 14 Mar 2004 (2 posts) Archive Link: "uml-patch-2.6.4-1"

Topics: User-Mode Linux, Version Control

People: Jeff Dike

Jeff Dike said:

This patch updates UML to 2.6.4. Besides the update, there were the following changes since the last patch:

The 2.6.4-1 UML patch is available at
http://www.user-mode-linux.org/mirror/uml-patch-2.6.4-1.bz2

BK users can pull my 2.5 repository from
http://www.user-mode-linux.org:5000/uml-2.5

For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

17. New "Umbrella" Security Project For Linux On Handheld Devices

12 Mar 2004 (2 posts) Archive Link: "[ANNOUNCE] Umbrella - process based mandatory access control"

People: Kristian Soerensen

Kristian Soerensen said:

I am proud to announce the official launch of the Umbrella security project for Linux on handheld devices.

Umbrella implements a combination of process based mandatory access control and authentication of files. Umbrella relies on the efford of developers, in order to implement a secure system. It is our philosophy that it is not possible to make a secure Linux system without involving the developers of the various applications used on the system!

The design of Umbrella is aimed to be very simple for developers to use and understand. It is not possible to make an ambiguous security configuration for Umbrella - unlike more complex security mechanisms like e.g. Security-Enhanced Linux.

You may find more details below and on our web site:
http://umbrella.sourceforge.net

-- UMBRELLA INTRODUCTION --

In designing Umbrella for handheld devices, there are several criteria that differ from that of regular computer systems. The most important are the available resources and the fact that heavy change in software do not occur. Furthermore the PDA, used for test purposes in this project, is not a development tool only a computer intended to do specific tasks such as organizer, email, games, communication etc.

Though resources on handhelds are limited, the devices has become increasingly more powerful and able to run a wide range of programs from different vendors. Umbrella is designed, such that software can be executed in a secure manner and thereby protecting the system against malicious code and viruses.

The overall structure of Umbrella is a mandatory access control scheme for running processes together with an authentication of files and run time integrity checking of the executables.

-- PROCESS BASED MAC --

The idea of processes based mandatory access control is strongly supported by the tree structure for processes in Linux.

Umbrella gives every process in Linux a set of restrictions. The rule is that every process must be at least as restricted as it parent. In practice, this works as inheritance: When forking a new process, it immediately gets the restrictions of it's parent, and if the parent have specified more restrictions for it's child(ren) then the "child restrictions" and the restrictions of the parent are combined (a union of the two sets of restrictions).

-- WHAT IS RESTRICTIONS? --

A restriction is just a string, e.g. "/etc/index.html". These strings can represent a path in the file system e.g. "/etc/passwd/index.html" or "/etc/index.html" or the restriction can represent a special ability e.g. "net" or "fork".

A path restriction restricts the process from the specified directory and everything below it. If the path-restriction is a file, nothing below exists, and the process is thus restricted from that single file only.

Ability restrictions is used to restrict from special operations, that cannot be restricted through files. An example of this is the network, which is only handled through the kernel. The restrictions for the network, the ability to fork new processes and others is handled within Umbrella.

It will be very easy to add new path restrictions to the system, as the way they are handled within the kernel are the same. From a user/programmer point of view, the interface will be made very simple (not implemented yet). Adding more ability restrictions require small modifications of the Umbrella code (hook implementations). At first we aim to implement the general, but simple, ability restrictions (like net and fork). However it is fairly easy to extend these to implement more fine grained restrictions.

In a subsequent post, he said:

Umbrella-0.2 can be downloaded from:
http://prdownloads.sourceforge.net/umbrella/umbrella-0.2.tar.bz2?download

The tarball includes detailed instructions for how to try out Umbrella.

18. udev 022 Released

12 Mar 2004 (1 post) Archive Link: "[ANNOUNCE] udev 022 release"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control

People: Greg KH

Greg KH said:

I've released the 022 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022.tar.gz (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-022.tar.gz)

rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.i386.rpm (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.src.rpm (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.src.rpm)

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ)

For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)

There are a few minor bugfixes in this release, and a few new features. Which pretty much seems to prove my "udev is mature" statement I made for the last release :)

Oh, I'd like to thank OSDL for doing some preliminary speed tests (as well as functionality tests) on udev. Unofficially it looks like it only took 7 seconds extra to use udev to name 1000 scsi disks (and the rule was calling out to scsi_id for every disk, and then parsing over 1000 rules.) Note that is 7 seconds extra to name _all_ of the disks at once using the scsi_debug module. That's not too shabby at all.

Where are those "hotplug is too slow to do device naming" whiners now...

Major changes from the 021 version:

Again a big thanks to Kay Sievers for sending me patches faster than I can integrate them. udev is a viable program due to his excellent work.

Thanks also to everyone else who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

19. Linux 2.4.26-pre3 Released

13 Mar 2004 (1 post) Archive Link: "Linux 2.4.26-pre3"

Topics: FS: NFS

People: Marcelo Tosatti

Marcelo Tosatti announced 2.4.26-pre3, saying:

Here goes the third pre release of 2.4.26.

It contains a bunch of NFS client fixes, IA64/32-bit PPC updates, sisfb update, amongst others.

20. Highpoint-Tech Plugin 0.0.1 For EVMS 2.3.0

14 Mar 2004 (1 post) Archive Link: "[ANNOUNCE] Highpoint-Tech Plugin 0.0.1 for EVMS 2.3.0"

Topics: Disk Arrays: EVMS, FS: sysfs, PCI

People: Wilfried WeissmannKevin Corry

Wilfried Weissmann announced:

...so here comes 0.0.1! i have changed the device manager id to 3 because of Kevin Corry suggested this and also added more pci-ids. you can override the id scan be setting "biosraid.ignore_pci_ids" to "1". but you still need the proper raid signatures on your disks to get a raid volume.

basic read/write tests on a fat partition worked fine, but i cannot do more right now. the fan of my graphiccard is broken and i replaced the cooler with cpu heatsink and attached it with a string to the board. looks pretty crude!

Changelog:

TODOs:

the next thing that i want to do is to implement the "whole disk" volume. it might be handy to have such a device for the grub bootloader and stuff. this also is a start for the last sector problem fix. the problem is that i should protect the sector #9 which contains the volume configuration. i do not think that it is possible to only write protect that sector but this would be a nice thing to do. the patch that applies against evms 2.3.0 is attached...

21. Status Of Software Suspend

15 Mar 2004 - 16 Mar 2004 (8 posts) Archive Link: "The verdict on the future of suspending to disk?"

Topics: Software Suspend

People: Nigel CunninghamKarol KozimorPavel Machek

Nigel Cunningham asked:

Just wanting clarification; what are we thinking about the future of suspend implementations? Let me throw my current understanding/suggestion in for starters:

Karol Kozimor said, "Patrick has been silent for months, which apart from further complicating matters makes any assumptions not quite right :)" . Pavel Machek said he didn't care which implementation was dropped as long as one remained. He also said to Nigel, "I do not think Patrick is going to maintain anything. If you want to maintain it, you can have it. Big plus if you are able to deal with Patrick." There followed a bit of an implementation discussion, which petered out quickly.

22. Linux 2.6.5-rc1 Released

15 Mar 2004 - 17 Mar 2004 (15 posts) Archive Link: "Linux 2.6.5-rc1"

Topics: I2C, Kernel Release Announcement, Serial ATA, Sound: ALSA, Version Control

People: Linus Torvalds

Linus Torvalds announced 2.6.5-rc1, saying:

Here's the current set of patches I've merged from various poeple..

Merging from Andrew, but also i2c updates, ALSA CVS merge, netconsole, prism54 driver merge, sata updates, carmel driver, pcmcia and nfs client updates..

And a few architectures updated: ia64, ppc32, sparc32, arm.

23. Linux 2.6.5-rc1-mm1 Released

16 Mar 2004 - 17 Mar 2004 (13 posts) Archive Link: "2.6.5-rc1-mm1"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced 2.6.5-rc1-mm1, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc1/2.6.5-rc1-mm1/

24. Linux 2.4.26-pre4 Released

16 Mar 2004 (1 post) Archive Link: "Linux 2.4.26-pre4"

Topics: Disk Arrays: RAID, Disks: IDE

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.26-pre4, saying:

Here goes the fourth -pre of 2.4.26.

Pretty small (great!), containing a few network updates, SPARC64 fixes, Bluetooth fixes, IDE update (fixes for AMD chipset driver and inclusion of Medley software RAID driver by Thomas Horsten), amongst others.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.