Table Of Contents
|1.||20 Sep 2003 - 28 Sep 2003||(6 posts)||Setuid Bug In Recent 2.6-test Kernels|
|2.||22 Sep 2003 - 29 Sep 2003||(20 posts)||Hyperthreading Configuration Questions For 2.4|
|3.||22 Sep 2003 - 29 Sep 2003||(97 posts)||More BitKeeper Debate; 'Arch' A Potential Replacement|
|4.||25 Sep 2003 - 26 Sep 2003||(4 posts)||Full-Time Developer For Software Suspend|
|5.||26 Sep 2003||(9 posts)||Using VMWare Under 2.6 Kernels|
|6.||26 Sep 2003||(3 posts)||Updated exec-shield Patch Released For Several Kernel Trees|
|7.||26 Sep 2003 - 28 Sep 2003||(13 posts)||Restricting Untrusted Binaries|
|8.||28 Sep 2003 - 29 Sep 2003||(9 posts)||Possible Linksys GPL Violations: The Saga Continues|
Mailing List Stats For This Week
We looked at 1483 posts in 6699K.
There were 435 different contributors. 205 posted more than once. 150 posted last week too.
The top posters of the week were:
Setuid Bug In Recent 2.6-test Kernels
20 Sep 2003 - 28 Sep 2003 (6 posts) Subject: "suid bit behaviour modification in 2.6.0-test5"
Topics: FS: XFS
People: Jean-pierre Cartal, Ian Hastie, Andries Brouwer, Bill Davidsen
Jean-pierre Cartal noticed that the 2.6-test behavior had changed relative to 2.4, in that "suid root files don't loose their suid bit when they get overwritten by a normal user." He asked if this was intended, or a bug. Ian Hastie confirmed the bahavior, saying, "it seems the bug is something to do with a directory listing cache somewhere. If you sync after copying over the file the suid bit is shown as having been cleared." Bill Davidsen asked what would happen if someone attempted to execute the program before the sync was done. Would it run with setuid powers?
At this point Andries Brouwer said that he'd already made a fix for this, and asked if it wasn't working. Ian replied that on his XFS filesystem, Andries' fix did not work. End Of Thread.
Hyperthreading Configuration Questions For 2.4
22 Sep 2003 - 29 Sep 2003 (20 posts) Subject: "HT not working by default since 2.4.22"
Topics: Hyperthreading, Power Management: ACPI
People: Marcelo Tosatti, Len Brown, Jun Nakajima, Jeff Garzik
Marcelo Tosatti pointed out:
Ive received a few complaints that HT, starting from 2.4.22, needs ACPI enabled. Users who had HT working now have to use ACPI and they didnt before.
We should have HT working AUTOMATICALLY without ACPI enabled and WITHOUT any special boot option, as before.
He asked Len Brown to take a look at it; and Jun Nakajima confirmed that Len was working on it. Len replied, "CONFIG_ACPI_HT_ONLY "CPU Enumeration Only" is under the CONFIG_ACPI menu at the request of Red Hat, who wanted to be able to disable anything to do with ACPI with a single option (CONFIG_ACPI). HT depends on this part of ACPI b/c the logical HT processors are enumerated using the ACPI MADT LAPIC entries." A couple posts down the line he proposed:
what to do?
We could make 2.4.23 like 2.4.21 where ACPI code for HT is included in the kernel even when CONFIG_ACPI is not set.
Or we could leave 2.4.23 like 2.4.22 where disabling CONFIG_ACPI really does remove all ACPI code in the kernel; and when CONFIG_ACPI is set, CONFIG_ACPI_HT_ONLY is available to limit ACPI to just the tables part needed for HT.
I'd prefer the later (doing nothing) because CONFIG_ACPI really should exclude all of ACPI. If we start including bits of ACPI without CONFIG_ACPI, where do we stop?
I'm not sure how to address "compatibility" and "regression" concepts in the face of changing config files. Make oldconfig will ask you about CONFIG_ACPI -- perhaps I should update the help text to emphasize that it is necessary for HT, and that if selected, CONFIG_ACPI_HT_ONLY is then available?
Is defconfig used? Does it define "compatibility"? If so, we could define CONFIG_ACPI && CONFIG_ACPI_HT_ONLY in defconfig to get the 2.4.21 behavior -- then could have our cake and eat it too.
I don't feel strongly about which way to go, but I will want to keep 2.4 and 2.6 as similar as possible in this area.
Marcelo affirmed that "CONFIG_ACPI_HT should be not dependant on CONFIG_ACPI." He asked Len to make it clear in the configuration that this dependency did not exist, and to move the CONFIG_ACPI_HT item out of the ACPI section. Jeff Garzik suggested that it might be confusing to see "ACPI" in the name of a configuration option that was outside of the ACPI section, and proposed "CONFIG_HYPERTHREAD" or "CONFIG_HT" as alternatives. But Len opposed the change, on the grounds that the current name accurately described the true situation. Jeff again said that "CONFIG_HT" would be much clearer to the reader; but Len insisted, "The problem is that "!CONFIG_HT" is meaningless. It implies that you can have CONFIG_ACPI but still "config-out" HT, which you can't." Len stood firm, but said he did implement Marcelo's requirements; and the thread ended.
More BitKeeper Debate; 'Arch' A Potential Replacement
22 Sep 2003 - 29 Sep 2003 (97 posts) Subject: "log-buf-len dynamic"
Topics: Version Control, Virtual Memory
People: Linus Torvalds, Andrea Arcangeli, Larry McVoy, Roman Zippel, Eric W. Biederman, Miles Bader, Davide Libenzi, Marcelo Tosatti, Jeff Garzik, Pau Aliagas
In the course of discussion, Andrea Arcangeli remarked that if Marcelo Tosatti used an open source tool instead of BitKeeper for development, it would be possible to modify the tool to solve a particular changelog feature that seemed desirable. Linus Torvalds replied:
Andrea - please just shut up.
Until you can point to anything even _remotely_ as good as BitKeeper, there's no point in just continually trying to start a flame-war.
I agree that Larry ends up being a jerk about it too, but I can well see that he reacts negatively to your totally unproductive comments.
BK has the email in the meta-data already, and a lot of tools to extract all the necessary data from mailboxes etc.
In other words, your argument is nonexistant, and your whole posting is pointless - except as flame-bait. And yes, Larry likely _will_ eat your bait, something I've berated him for in private emails several times.
So shut up or put up. Go off and write your own tool. In the meantime, stop complaining about people who wrote _their_ tools and selected a license that you wouldn't choose.
When you write some code of your own, you get to choose the license. And I haven't seen you make CVS usable - I've only seen you bitch, moan, and complain..
Andrea replied, "if I would know that you will eventually get interested into anything not bitkeeper I would be glad to hack in this area (I can use some spare time too) to provide a service to the community. The main reason I will never use b*tkeeper is because I want to retain the freedom to do that, something that you and many others won't be able to do anymore." He suggested that CVSPS and Subversion might be adequate for kernel development. Linus replied:
Neither of those are anywhere close to bk.
In particular, they don't support any kind of distributed development. They aren't even trying to, I'm sad to say. And to me, distributed development is the only thing that matters.
And I realise it isn't to you. You don't much care about merging, you only have your tree you need to worry about.
And you know what? You shouldn't have to care. I'm not berating you for using CVS/SVN/whatever. I'm berating you for complaining when _others_ have come to the conclusion that CVS/SVN/whatever really doesn't cut it for them.
Use CVS and be happy. But don't complain to others that have needs that CVS simply can't fill.
In the same post, he added:
I don't care about source control software, so I'm not likely to start coding one any time soon (like "ever") - but if I did, I'd be totally _ashamed_ to push lower-quality stuff on users. I'd make excuses for it, and I'd 'fess up when they didn't work. And I'd try my best to make it better. Even if it took me a decade.
In contrast, what you're doing is saying "ignore the good stuff: use this crap, because I'm buddies with the people developing it. We aren't even trying to compete on technical terms, but we'll push our version on you because we've got religion, and this doesn't contain any cow-meat". That's bad - especially if others DON'T share the religion.
I'm ok with other people using NT. When it's better for them, that's their choice. I work hard to make sure that the Linux kernel is technically superior, and if I feel it isn't I want to fix it. Because I do _not_ want people using Linux for religious reasons. I want people to use Linux because it is _better_ for them, of because they truly believe that they can make it so (or at least have fun trying).
Take pride in what you do. But don't make that pride blind you to what is good technology, and what isn't. Don't get religion. It's a science.
At this point, Pau Aliagas suggested that arch (http://savannah.gnu.org/projects/gnu-arch) would do everything Linus needed and more. But there was no discussion about this.
Close by, Larry McVoy asked Andrea to stop "biting the hand that is held out to you." A couple posts later, Larry remarked that Andrea was not doing significant work in the kernel, and so did not deserve respect. Andrea pointed out that he had played a major role in the development of the Linux Virtual Memory subsystem, which he said was probably running on Larry's own systems. Larry said a Virtual Memory subsystem was child's play compared with his own accomplishments, particularly the VM subsystem he worked on for SunOS. At around this point Linus said:
Larry, I think you remember the good old days of SunOS, when 16MB of RAM was a lot, and people expected less of their hardware. In particular, interactive programs used to have a _tiny_ footprint. Often even under X.
Then we put Solaris, Motif and CDE on those suckers, and it was horrible.
Yeah, SunOS was nice. But I really think it's the access patterns that changed.
Elsewhere but close by, Linus said to Andrea, "your lack of interest in BK does _not_ explain why you whine about it, and try to goad Larry, and just generally are nasty about it." He said that a person had the right to choose the license under which they released their own code, and that no one had the right to get mad about it. Elsewhere he reiterated that Andrea's comments were impolite and even offensive; but Roman Zippel came in with, "You think this is impolite? I've been quiet lately in these flame wars, because I couldn't have staid that polite to an arrogant asshole, but I won't stay quiet when Larry can now insult other developers and gets away with it. If someone is whining around here, then it's only Larry. A lot of people are contributing to the kernel, but he is the only one constantly whining around that he should be treated special and makes silly threats. Can we please get cause and effect right here? Of course Larry is completely free to choose whatever license he wants, but advertising a stupid license in a free software environment will of course cause disagreement and complaints. There is _nothing_ anyone but Larry can do anything about it, but amazingly enough Larry manages to take every single complaint as personal insult and makes all of the bk flame wars worse than they already are."
Elsewhere, Eric W. Biederman said, "There are subprojects that are currently using BK that you can't even get the code without BK. And the only reason they are using BK is they are attempting to following how Linux is managed. So having the Linux kernel development use BK does have some down sides." Linus replied, "That's actually a pretty good point. I end up releasing "sparse" only as a BK archive, simply because I'm too lazy to care and there aren't enough people involved (and those that _are_ involved do actually end up re-exporting it as non-BK, but that doesn't invalidate your point). I don't know what the solution to it might be - but I don't think the reason they are using BK is that they are trying to emulate "the great kernel project". I know it wasn't for me - it's just that once you get used to BK, there's no way you'll ever go back to CVS willingly." Jeff Garzik affirmed that all his new projects used BitKeeper, because it was so much better than CVS. Linus also said, "As Larry will tell you, the technical problems are bigger than you imagine. So a BK killer won't be coming any time soon, methinks."
Elsehwere, Eric remarked that the arch tool did not handle distributed repositories or repo-to-repo merges very well, and Miles Bader replied, "Are you are kidding? Arch is _insanely_ good at handling both distributed repositories and merging -- those are if anything its greatest strengths. Everyday development of tla (the latest/greatest arch implementation) involves many people with their own repositories, merging back and forth." And Davide Libenzi added, "I definitely agree. It's about a couple of months that I'm playing with it and I have to say that it works great with distributed development. It basically born with that as the very first design rule. It also look very stable AFAICS. And, the old collection of shell scripts (that I didn't like in the beginning) is shaping out toward C code. In three words, I like it. I cannot compare it to bk because I never used it (not because of the license, and not even for political/personal reasons, but because I haven't had any time to do it in the past), and I am sure it still lacks of some useful features when matched with bk, but the fundamentals are definitely there."
Full-Time Developer For Software Suspend
25 Sep 2003 - 26 Sep 2003 (4 posts) Subject: "Announce/Thanks: Nigel Cunningham to work full-time on Swsusp for a while."
Topics: Software Suspend
People: Nigel Cunningham
Nigel Cunningham announced:
This is to announce that LinuxFund.org (http://www.linuxfund.org) have kindly agreed to support me while I work on Software Suspend full time for a while, beginning 1 October.
This development should lead to a faster completion of the 2.4 version, and a faster release of the port to 2.6. Lord willing, a test version of Software Suspend for the 2.6 kernel that has all the features of the 2.4 version will be available within a couple of weeks.
Several folks offered their congratulations.
Using VMWare Under 2.6 Kernels
26 Sep 2003 (9 posts) Subject: "vmware in Linux 2.6"
Topics: Networking, Power Management: ACPI
People: Petr Vandrovec, Jan Rychter, Mans Rullgard
Mans Rullgard asked about VMWare under Linux 2.6, as the kernel modules would no longer compile with recent kernels. The vmmon module in particular gave big errors, and Mans could find nothing about it on google. Martin Zwickel and Petr Vandrovec said that the problems were probably addressed in 'vmware-any-any-update40'. Petr added, "And except that this patch makes thing compilable, it also makes driver a bit friendlier to the MM subsystem, it allows you to use VMware on 4G/4G host, and it properly handles bridged networking on adapters using hardware (or pseudohardware...) Tx checksumming (although only for IPv4 due to features of dev_queue_xmit_nit)." Jan Rychter added, "For those who run VMware on notebooks with ACPI, another patch is necessary, otherwise ACPI C-states handling doesn't notice VMware and as a result the guest system is unbearably slow." Petr asked, "If this patch is for vmmon, can you share it with VMware (or with me and I'll then share it with VMware) ? I cannot explain why ACPI does not notice that kernel is spending about 99% of time in the kernel, being very busy with hard work..." Jan didn't reply on the list, but in his earlier post he'd also asked if VMWare rolled patches like this back into their own sources, for public release, and Petr said, "Yes. Currently VMware's & mine code is identical except that mine vmmon supports all released products since VMware 2.0.0 through VMware express, GSX & so on up to the VMware 4.0.2, while VMware's code supports only product it is shipped with. And you need C++ (for templates which are used for generating code for different product versions) with mine code, while you get one unwind template instance from VMware."
Updated exec-shield Patch Released For Several Kernel Trees
26 Sep 2003 (3 posts) Subject: "[patch] updated exec-shield patch, 2.4/2.6 -G3"
People: Ingo Molnar, Valdis Kletnieks
Ingo Molnar announced:
in the recent boom of buffer-overflow bugs in various open-source packages i got lots of requests for exec-shield being ported to various popular kernel trees. Here's the latest update of exec-shield:
against vanilla 2.6.0-test5:
against vanilla 2.4.22:
against 2.4.22-ac + NPTL:
[ redhat.com/~mingo/nptl-patches/nptl-2.4.22-ac1-A2 ]
Changes in this exec-shield version:
- more refined support for PIE binaries (Position Independent Executables
- a feature of latest binutils)
- complete randomization of the whole address space [except the static binary mappings for non-PIE binaries]. Randomized executable mappings, heap, data mappings, stack, env/argv/aux spaces. With PIE binaries there's not a single constant address left.
- ability to turn off exec-shield without changing the binary. (try 'setarch i386 /bin/cat /proc/self/maps'.)
- various compatibility features and fixes.
- randomization can be turned off via /proc/sys/kernel/exec-shield-randomize.
valid /proc/sys/kernel/exec-shield levels are:
= 0 exec-shield disabled
= 1 exec-shield on PT_GNU_STACK executables [ie. binaries compiled with newest gcc]
= 2 (default) exec-shield on all executables
value 1 is recommended with glibc and gcc versions that support PT_GNU_STACK all across the spectrum. (Fedora Core test2 [released yesterday] includes all of this and all applications were recompiled to have valid PT_GNU_STACK settings.) On other systems the value of '2' is recommended, use setarch for those binaries that cannot take exec-shield [eg. Loki games].
Valdis Kletnieks was really happy to see this, saying, "I'm using a fairly current Rawhide here (within last 2 weeks or so). Applied with 2 or 3 minor conflicts and a few fuzz/delta messages against -test5-mm4 (I have a refactored patch if anybody is interested). It booted OK, seems to be working well enough that e-mail and XFree (even with the evil binary NVidia driver) are functional." Ingo remarked, "btw., i have a patch against Linus' latest, -bk12 too: redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-bk12-G2 (http://redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-bk12-G2) "
Restricting Untrusted Binaries
26 Sep 2003 - 28 Sep 2003 (13 posts) Subject: "Syscall security"
People: Maciej Zenczykowski, Chris Wright, Muli Ben-Yehuda, Muli
Maciej Zenczykowski requested:
I'm wondering if there is any way to provide per process bitmasks of available/illegal syscalls. Obviously this should most likely be inherited through exec/fork.
For example specyfying that pid N should return -ENOSYS on all syscalls except read/write/exit.
The reason I'm asking is because I want to run totally untrusted statically linked binary code (automatically compiled from user submitted untrusted sources) which only needs read/write access to stdio which means it only requires syscalls read/write/exit + a few more for memory alloc/free (like brk) + a few more generated before main is called (execve and uname I believe).
Currently I'm running the code in a chroot'ed environment (to an empty dir) under a 'nobody' uid/gid with no open fd's except for std in/out/err with limits for mem, processor usage, open files, processes (to 1), etc. Obviously this still allows calling code like 'time', 'getuid', etc and the like. Modifying the compiler (or removing the headers) won't help since at worst I can code it in asm in the source or even in a plain byte table.
I have a working (very much a hack) patch which turns of all but 7 (or so) of the syscalls (via pseudo-bitmaps).
Basically my question is: has this been done before (if so where/when?), what would be considered 'the right' way to do this, would this be a feature to include in the main kernel source?
Joe McClain recommended Systrace (http://www.citi.umich.edu/u/provos/systrace/) . Chris Wright also said to Maciej, "A simple LSM module can do this for you. It will have a little more overhead than denying at the syscall entry point, but it's certainly going to be more flexible." Muli Ben-Yehuda also replied to Maciej, saying, "syscalltrack can do it, per executable / user / syscall parameters / whatever, but it's per syscall. Writing a perl script or C program to iterate over the supplied syscall list and write the allow/deny rules is pretty simple. Also, syscalltrack is meant for debugging, not security, so if you want something that's 100% tight you'd better go with one of the Linux security modules based on the LSM framework."
Possible Linksys GPL Violations: The Saga Continues
28 Sep 2003 - 29 Sep 2003 (9 posts) Subject: "Linksys WRT54G: Part 2"
Topics: FS: CIFS, FS: ramfs, Networking, Samba
People: Andrew Miklas, Rob Landley, Erik Andersen, Rik van Riel, Alan Cox, Jeremy Allison
For earlier discussions of this, see Issue #219, Section #16 (7 Jun 2003: Possible GPL Violations By Many Wireless Vendors) , and Issue #221, Section #8 (24 Jun 2003: More On Possible GPL Violations By Wireless Vendors) . This time, Andrew Miklas began the current thread with:
A few months ago, I wrote to the kernel list describing the relationship between Linksys (now business unit of Cisco Systems), their WRT54G 802.11g wireless home gateway, and Linux. At the time, we had recently discovered that the WRT54G was using a great deal of software made available under the GPL, but was not giving credit to the authors, or providing the source as required by the GPL.
After a bit of public pressure, Linksys posted their "GPL Code Center" , where they claim that "the GPL source code contained in this product is available for free download" . Shortly after the code center was made available, a group of developers pointed out to Linksys that their source code, particularly their Linux kernel code, was incomplete.
Previously, it was thought that the WRT54G source releases had only neglected to include the source code for the various kernel modules used to run the ethernet and wireless interfaces. However, at this time, it is clear that the kernel proper of the WRT54G itself has had functionality added to it. This functionality is not present in the kernel code that Linksys has provided at their "GPL Code Center".
That is to say, there is code STATICALLY LINKED with the Linux kernel running this device that is not present in the source download. This code seems to be shared between the Broadcom ethernet and wireless chips. It appears to be primarily responsible for configuring the Sonics' SiliconBackplane and handling DMA transactions for both devices.
The incompleteness of the kernel source can be demonstrated as follows:
Download the kernel source provided by Linksys from:
(Note: at this time, the kernel source provided for firmware versions 1.30.1, 1.30.7, and 1.41.2 are identical, so it doesn't actually matter which one you download.)
- Untar the archive and run:
- Notice it fails:
drivers/net/Config.in: 5: unable to open drivers/net/hnd/Config.in
make: *** [kconfig.tk] Error 1
make: Leaving directory `/home/andrew/linux-kernel/linux/scripts'
make: *** [xconfig] Error 2
- When it asks:
Network device support (CONFIG_NETDEVICES) [Y/n/?]
- Notice it fails:
scripts/Configure: line 5: drivers/net/hnd/Config.in: No such file or directory
make: *** [config] Error 1
- As you can see, it is not possible to compile a kernel with the provided build utilities with networking support.
- Download a copy of the firmware image for the 1.30.7 firmware from:
- Extract the CramFS filesystem and kernel image:
dd if=WRT54G_1.30.7_US_code.bin of=cramfs.image bs=786464 skip=1
dd if=WRT54G_1.30.7_US_code.bin bs=60 skip=1 | zcat > kernel
Mount the filesystem, and run "nm" against the wireless driver:
(You'll need to have CramFS compiled in or available as a module.)
mount cramfs.image /mnt/rom -o loop
nm /mnt/rom/lib/modules/2.4.5/kernel/drivers/net/wl/wl.o > wl_syms.txt
For convenience, a copy of the output of this command is available at:
- Notice that the driver wl.o makes several imports from the kernel that are not included in a stock 2.4.5 kernel. In particular, note that the symbols bcm_*, pkt*, dma_*, sb_*, osl_*, and srom_* are imported by the module, but not included in the kernel source.
- Verify that the symbols aren't provided by another module by running "nm" on them.
Download a copy of ksyms_sorted.txt:
This is a copy of the /proc/ksyms file from a running WRT54G (firmware 1.30.7). The entries have been sorted by address to make reading it a bit more convenient.
The raw, unsorted output is also available:
Find the symbols that were missing from the kernel image:80094f18 bcm_strtoul 800950a4 bcm_atoi 80095100 deadbeef 80095140 prhex 80095258 prpkt 800952bc pktcopy 800953a4 pkttotlen 800953c4 bcm_ether_ntoa 80095420 bcm_ether_atoe 800954a4 bcm_parse_tlvs 800954f4 pktqinit 80095508 pktenq 8009554c pktdeq 8009558c getvar 8009563c getintvar 80095674 bcm_mdelay 800956b4 crc8 800956f4 crc16 8009574c crc32 800958c0 dma_attach 80095a64 dma_detach 80095ad0 dma_txreset 80095be0 dma_rxreset 80095c40 dma_txinit 80095ca4 dma_txenabled 80095ccc dma_txsuspend 80095ce0 dma_txresume 80095cf8 dma_txsuspended 80095d28 dma_txstopped 80095d40 dma_rxstopped 80095d58 dma_fifoloopbackenable 80095d6c dma_rxinit 80095dc4 dma_rxenable 80095ddc dma_rxenabled 80095e04 dma_txfast 80095ff4 dma_tx 8009629c dma_rx 80096380 dma_rxfill 800964e0 dma_txreclaim 80096530 dma_getnexttxp 80096604 dma_rxreclaim 80096648 dma_getnextrxp 800966cc dma_dumptx 80096760 dma_dumprx 800967f4 dma_dump 80096824 dma_getvar 80096870 osl_pktget 80096934 osl_pktfree 80096a98 osl_pci_read_config 80096ad0 osl_pci_write_config 80096b00 osl_pcmcia_read_attr 80096b08 osl_pcmcia_write_attr 80096b10 osl_assert 80096bb8 sb_attach 80096c38 sb_kattach 80096f30 sb_coreid 80096f48 sb_coreidx 80097028 sb_corevendor 8009703c sb_corerev 80097050 sb_coreflags 800970b8 sb_coreflagshi 80097120 sb_iscoreup 8009736c sb_detach 80097504 sb_setcoreidx 8009761c sb_setcore 80097660 sb_chip 80097668 sb_chiprev 80097670 sb_boardvendor 80097678 sb_boardtype 800979a0 sb_boardstyle 80097a48 sb_bus 80097a50 sb_corelist 80097a88 sb_coreregs 80097a90 sb_taclear 80097b04 sb_commit 80097b8c sb_core_reset 80097d04 sb_core_tofixup 80097dc0 sb_core_disable 80097f34 sb_watchdog 80097f98 sb_pcmcia_init 8009803c sb_pci_setup 80098198 sb_base 800981e0 sb_size 8009823c sb_coreunit 800982b0 sb_clock_rate 80098548 sb_clock 800985f4 sb_gpiosetcore 80098614 sb_gpiocontrol 80098680 sb_gpioouten 800986e4 sb_gpioout 80098748 sb_gpioin 800987a8 sb_gpiointpolarity 8009880c sb_gpiointmask 80098870 sb_dump 80098990 srom_var_init 80098a10 srom_read 80098b08 srom_write 80098d7c srom_parsecis 8014ba80 bcm_ctype
You can also find the symbol names in the kernel by grepping through the output of "strings" on the kernel image produced in step two.
Note that the addresses at which these symbols are located are used by the kernel proper. Kernel modules get loaded to a different address range. Also note that these symbols are surrounded by other symbols included in a stock Linux kernel.
The above analysis shows that the kernel source provided by Linksys cannot be compiled in a configuration that would be of use on the WRT54G. Even if it could, functions necessary for the networking subsystem would be missing, making the loading of the ethernet and wireless drivers impossible. Clearly, the kernel source that Linksys provided cannot be used to recreate the kernel that they are shipping with their product. Therefore, they have been, and still remain in violation of the GPL.
Until now, we have held off highlighting this fact in the hopes that Linksys would realize their omission and correct it. Unfortunately, after three releases of their firmware (1.30.1, 1.30.7, 1.41.2), and numerous notices from many individuals explaining this oversight, it seems that Linksys has no intention of correcting this problem.
The lack of complete source code for the kernel present on the WRT54G is hindering a number of very interesting development efforts. The SeattleWireless WRT54G group  is working toward creating completely new firmware images for the WRT54G. However, they are unable to create a kernel for this device, largely because any kernel they compile will be unable to load the modules necessary to support the ethernet and wireless devices. This limits the functionality that they can add to their project.
The Linux Broadcom 4301 project  is attempting to create a driver to support the Broadcom 43xx series of wireless devices on generic hardware. Their work would be greatly lessened if they could at least be sent the source code for the parts of the wireless driver implemented in the kernel proper.
It is also worth noting that this is not the only Linksys device that uses Linux and other software licensed under the GPL without adhering to the license. For example, the Samba team has expressed some concern over the use of Samba in the Linksys EFG80 network accessible storage device .
Also, the following products seem to be based on the same general design as the WRT54G, and therefore suffer from the same problem described above. However, at this time, no source for either device is available from the "GPL Code Center". - Linksys WRT55AG Dual-Band Wireless Router  - Linksys WAP54G Wireless-G Access Point 
Unfortunately, neither group knows how to proceed in obtaining this code. While Linksys has shown some interest in releasing the source for software licensed under the GPL, they have not responded to the issues outlined in this post.
If anyone wishes to contact Linksys concerning this matter, we'd recommend you try the following address: [opensource () linksys ! com]. However, since we have never received a response to messages directed at this box, you may want to CC any messages to [pr () linksys ! com] or perhaps [mailroom () linksys ! com] as well. With any luck, we will eventually sort out this issue.
The data contained in this post were produced by many individuals working on a variety of Linksys products. Therefore, while every effort has been made to ensure that the information contained in this post is accurate, it is entirely possible that we've made some errors. If that is the case, please let us know and we will correct the mistake.
(in alphabetical order)
jra () samba ! org
andersen () codepoet ! org
kendallb () eden ! rutgers ! edu
Linux Broadcom 4301 Driver Project
Jim () Buzbee ! net
alan () lxorguk ! ukuu ! org ! uk
rob () oreillynet ! com
SeattleWireless WRT54G Project
Christopher R. Hertel
crh () samba ! org
Samba Team and jCIFS Team Member
kaloz () dune ! hu
public () mikl ! as
Linux Broadcom 4301 Driver Project
brettw () riseup ! com
Linux Broadcom 4301 Driver Project
 Linksys GPL Code Center
 WRT54G firmware download page
 Linux Broadcom 4301 Driver Project
 Linksys EFG80 Network Attachable Storage Product Page
 WRT55AG Dual-Band Wireless A+G Broadband Router
 WAP54G Wireless-G Access Point
For some reason, there doesn't appear to be a link to the firmware from this page, but it can be downloaded from the following address:
Rob Landley suggested that probably Linksys itself was unaware of the problem, or why would they create a GPL Code Center for incomplete code? He guessed that probably the technical guys who knew all the relevant details might have left the project or the company, leaving only management or an outsource company to deal with it. He suggested, "Keep the pressure up, but be nice and give them some time to audit their codebase. Firmware development was probably outsourced to india or taiwan or something, and Linksys (nee Cisco) is quite possibly furious at whoever they outsourced this to for putting them in this position in the first place..."
Erik Andersen replied:
Nope. It is absolute certainty they know about it. I had my lawyer contact them months ago, and the cisco Legal department was made aware of this and other problems, and responded that
"the Linksys technical folks are digging into your questions - all the the software in question is from Linksys' suppliers (Linksys doesn't have the source code to this software), so we have to work with these suppliers to address any concerns."
but that was July 15 and I have heard nothing substantive from them since that time.
He also said:
How much niceness do they need? I had my lawyer send the first of several letters (nice and polite) on 8 May... After several additional letters (increasingly less polite) my lawyer and I were finally contacted by Cisco on June 20. They stated at that time "We are in the process of determining what code is subject to the distribution obligation; once we have done so, all such code will be made available under the terms of the GPL."
On July 10 they informed us they were setting up their GPL Code Center. We informed them on that data that (at least) the WRT55AG, and WAP54G products also contain Linux and need to have the GPL'd sources published. We also informed the Cisco legal dept on July 10 that they have have not provided source code for 'libnetconf' (which staticly includes iptables/netfilter code), and since they have shippied zillions of these things, they are obligated to release source not just libnetconf, but also all applications linked with libnetconf.
They have not yet addressed that issue despite 2.5 months passing since their legal department was informed. When combined with the issue of the broken kernel they distribute, it is hard to argue they have acted in good faith at complying.
Rik van Riel replied:
I have no idea who their supplier is, but it's not unthinkable that the supplier is trying to take advantage of the situation by asking extraordinary amounts of money from Cisco and/or Linksys in order to give them the source code.
Hell, their contractor could even have removed the source code from their systems already ("mmm, the disk is full, lets remove some old projects").
Personally I'd like to treat Cisco and Linksys nicely for the time being, since the full extent of the nasty situation they're in could well be covered in an NDA with their contractor, making them unable to tell us the reasons for the way things are going.
We Hope You Enjoy Kernel Traffic
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.