The August 2001 LJ's At the Forge is about a feature of Enhydra. Enhydra is commercial software, based on Java, which is commercial software. As far as I can see, there is no mention of Linux or anything specific to Linux in the article. It would not be out of place in a magazine called Web Automation, but I fail to see why it belongs in a magazine devoted to Linux, and more generally, to free software.
—Carl Fink
Reuven replies: While Java isn't free software, many web developers want or need to use Java in their work. I cannot change the Java license, but I can encourage Java developers to use an open-source operating system (Linux) and an open-source application server (Enhydra). So far as I understand it, there are two different ways to get Enhydra. The first is to obtain the core Enhydra application server, which is freely downloadable and distributable. This includes XMLC, DODS, super servlets and all that other stuff. The license agreement for this is indeed open source, despite what you might read elsewhere on the Enhydra web site. Here are three URLs about the licensing scheme: www.enhydra.org/aboutEnhydra/index.html, enhydra.enhydra.org/software/license/rationale.htm and enhydra.enhydra.org/software/license/opl.html. The second way is to get the Lutris EAS (Enhydra Application Server), which is a commercially packaged and tested version of the open-source stuff. I believe that you pay $995 US (or so) per CPU for EAS, but you're paying for the support, not for the server itself, in a twist on the open-source model. You could also argue that my article about PostgreSQL wasn't specifically about Linux, but the fact is that there are many people interested in using that database on Linux. For better or worse, there are lots of Linux devotees who also want to be able to use Java. Indeed, as someone who does web development on Linux every day (and many nights) of the week, I'm happy to know that I can now talk to clients about a serious Java and EJB solution that goes above and beyond Jakarta-Tomcat.
I really enjoyed the article “Loadable Kernel Module Exploits” by William Benton in the September 2001 issue of Linux Journal. I know that such articles are not meant to be exhaustive, but there is one bug in the Checking and Logging Function Listing on page 26 that I consider to be critical. The code hooks into the sys_call_table by saving the current address of SYS_write and replacing it. It unhooks by putting back the saved address. The bug is if there is more than one such hook. If another module hooks the SYS_write entry after this module, then an rmmod is done on this module, and the other module will become unhooked.
An even worse scenario is possible: 1) Module A is insmod-ed and hooks SYS_write. SYS_write points to wrapped_write in module A, orgwrite points to the previous contents (assume it is the normal entry). 2) Now module B does the same. SYS_write points to, say, modified_write in module B, orgwrite points to wrapped_write in module A. 3) Module A is rmmod-ed. SYS_write now contains the original SYS_write value. But this means that modified_write in module B is now bypassed. 4) Now module B is rmmod-ed. The cleanup_module in module B will restore the SYS_write table entry to point somewhere where module A used to reside. 5) Linux will most likely crash.
Unfortunately, I am not really a kernel hacker, so I don't know how I could tell the rmmod function that I don't want to be removed. To be safe, you would need to rmmod in the reverse order that you insmod-ed. I don't know enough about Linux to say how this could be accomplished.
—John McKown
Benton replies: You are correct; the situation you describe can be a problem for production code if a system administrator is not careful. I had not assumed that it would be a serious issue in example code (or in production code with a vigilant system administrator), but it is good to identify possible pitfalls in kernel programming. One (simple) solution is to be careful what you load and unload and in what order. As the old joke goes: “Doctor, it hurts when I do this!” “Well, don't do that, then!”. There are plenty of ways to crash your system poking around in the kernel, and it's best to avoid all of them once you've identified them. In all seriousness, these problems will exist as long as Linux does not provide a mechanism for registering changes to the system call table. I don't think they're horribly serious, since a degree of care on the part of the user can prevent a crash. However, there is a workaround that can give you some basic stability: in cleanup_module(), be sure to check whether the system call table entry that you're about to restore is what you think it should be. If not, issue a warning and invoke the sync() system call before modifying the system call table. That will minimize the damage in the event of a crash. As an alternative (and more difficult) solution, you could replace the create_module system call in the first module you load, wrapping it with one that provides some sort of versioning system for the system call table in a static stack or deque. I'll leave implementing that as an exercise for the reader.
Please congratulate Lydia Kinata for the magazine's new design. I have been waiting a long time for this kind of improvement. Best regards and keep improving.
—Jorge Carminati
I finally had time to read the September issue. The first thing I noticed was the new design. Looks great, keep the change! I've had a subscription for over two years and this, to me, was the best issue (look and content) I've received.
—Matt C.
Robin, I got a copy of the Linux Journal at LinuxWorld and read your article on DreamWorks—what a great visit that must have been!
Given what you saw there and may already know of, I was wondering if you could offer a suggestion. I have a teenage son that is very interested in animation, but the applications to do that are pretty expensive. Can you suggest some Linux-based rendering applications that are more affordable?
—Jack C.
Robin replies: Jack, we had a great time at DreamWorks. But DreamWorks is just the first. All the studios have Linux migration projects underway.
You may want to start with Blender, a popular, freely distributed 3-D modeling package for animation, rendering, interactive 3-D and game creation. Unlike most no-cost animation tools, there are printed books available on Blender. Other tools that may be of interest include K-3D, Ayam, AC3D, Flow, Radiance and BMRT. You can find their web pages by searching at Freshmeat.net
In the September 2001 LJ article “Loadable Kernel Module Exploit”, I was interested in the technique for hijacking the sys_call_table pointer and wrapping it within your own function. I used to do something very similar in DOS in the good ol' days, writing TSRs (Terminate and Stay Resident) and other programs that “borrowed” the bios or dos interrupts vectors.
For programs, it was a simple case of restoring the original interrupt vector (pointer), but with TSRs, one had to be careful before restoring the original pointer. The problem being that if several TSR utilities were installed, two might hijack the same interrupt (often the keyboard). A properly written TSR would, before uninstalling, check that the current pointer pointed indeed to itself, if it didn't, then it could not uninstall as by doing so it would clobber another, later installed, TSR.
The cleanup_module(void) routine in the article performs no such check before restoring the sys_call_table[SYS_write] pointer, something which at first sight appears dangerous to me in a multitasking environment, especially one where the kernel can load and unload modules automatically.
—John Jacq
