Letters

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.