LWN.net Weekly Edition for September 1, 2005 [LWN.net]

Linux and desktop graphics

There is a lot to be said for the X window system. It is, after all, one of the oldest and most successful free software development projects in existence. X helped to pioneer many concepts, including the idea of a graphical display as a network service and the absolute separation of graphical mechanism and policy. Long before Linux began to make proprietary Unix vendors worry, X was pushing aside proprietary desktop implementations.

X has a problem, however: it is very much a two-dimensional system in a three-dimensional world. It was designed around dumb frame buffers, but is now expected to run on graphical adaptors which, in terms of processor performance, far outclass the central processor they serve. As a result, X tends to make poor use of contemporary video hardware; it restricts itself to the hardware's two-dimensional processor (a nearly vestigial afterthought bolted onto the real hardware) and cannot make use of many of the capabilities provided by the 3D processor. X is, essentially, using a legacy interface which is poorly supported now, and which may go away in the near future.

To remain viable, and to help free operating systems develop the best desktop experience possible, X must grow into the current crop of hardware. The X developers have understood this for some time, and have been working in that direction. Events from this week demonstrate, however, that there is a lack of consensus on what needs to be done, and when.

The person driving the debate is Jon Smirl, an active graphics programmer. Frustrations with the X development process have led Jon to write and post a document called The State of Linux Graphics. Regardless of how one feels about Jon's opinions, the document is worth a read; it is a comprehensive overview of the problem and the current body of low-level graphical software. If you've ever wondered what all those acronyms (XAA, EXA, DRI, ...) mean, this document will clarify a number of things.

X developers seem to agree that X needs to make a switch from 2D to 3D hardware. There is less consensus on how the 3D hardware should be made available to user space. One approach is to make OpenGL be the API for next-generation graphics. This interface is relatively well designed, is open, and already has a certain level of support in free software. It is a high-level interface which allows an application to take advantage of the hardware's capabilities. OpenGL supporters see the X of the future as being a sort of management layer around the OpenGL interface.

Jon Smirl is one of those supporters. He has been working on Xegl, a version of the X server which makes the OpenGL interface available. A few weeks ago, however, Jon announced an end to his Xegl work. In his opinion, Xegl is not going to reach a usable state anytime soon, so it is not worth working on.

The problem, it seems, is that Xegl lacks developers and is progressing too slowly. According to Jon, a big part of the problem is that development work in the X community has been spread in too many directions. He is, in particular, critical of an effort called EXA, which is working to integrate drivers using the 3D hardware into the existing X API. EXA may have the effect of extending the life of the current X server, but it does relatively little to make the hardware's capabilities available to applications. As a result, the X server will be faster on supported hardware, but it will still be a 2D server. Says Jon:

End result is that EXA is just a bandaid that will keep the old X server code going another year or two. There is also a danger that EXA will keep expanding to expose more of the chip's 3D capabilities. The EXA bandaid will work but it is not a long term fix. Its existence also serves to delay the creation of a long term fix.

Jon seems to believe that the main thing EXA will accomplish is to push back the date when Xegl will show up as the real solution to the problem. He claims that Linux is already far behind the proprietary platforms in providing a desktop which can take advantage of contemporary hardware, and has little patience for developments which threaten to widen that gap. So Jon has stopped development work on Xegl, and is working for process change instead. His conclusion states:

As a whole, the X.org community barely has enough resources to build a single server. Splitting these resources over many paths only results in piles of half finished projects. I know developers prefer working on whatever interests them, but given the resources available to X.org, this approach will not yield a new server or even a fully-competitive desktop based on the old server in the near term. Maybe it is time for X.org to work out a roadmap for all to follow.

Not all X developers are entirely supportive of Jon's position. The administrator of freedesktop.org, where Jon's document is hosted, posted a dismissive response and promptly shut down Jon's account, making the document unavailable. It has since been restored, but that action (ostensibly taken for other reasons) added an unpleasant note to the debate.

Some developers seem to agree that the OpenGL approach is the right one for the long term, but they never believed that this solution could be implemented in the near future. It is, after all, a complex project. For these developers, EXA makes sense as a short term, relatively easy solution to make X functional on current hardware.

Others seem to disagree with the transition to OpenGL altogether. The current X Render extension makes a number of capabilities available to applications, and it could be extended where needed. Render is seen as a friendlier API for 2D applications than OpenGL. Not moving to OpenGL would mean less disruption for applications and would avoid impacting X performance on older hardware without 3D acceleration.

The discussion, as of this writing, has not reached much in the way of new conclusions. The Xorg project lacks a dictator, and will thus be hard put to pick a direction and expect that the developers will simply follow. What does seem clear, however, is that the developers are determined to bring X forward to where it is, once again, a leading-edge graphical platform. They will probably get there, one way or another.

Comments (30 posted)

The StorageTek DMCA decision

Last year, StorageTek (soon to be a subsidiary of Sun) brought a suit against Custom Hardware Engineering, alleging copyright and DMCA violations. CHE is a third-party maintenance vendor which was offering maintenance services for StorageTek's tape libraries. To carry out that maintenance, CHE built a gadget which would intercept diagnostic messages sent within the library; CHE also had to bypass StorageTek's "GetKey" system which protected access to those messages. StorageTek claimed that running the maintenance code (which generates the diagnostic messages) was a copyright violation, and that bypassing GetKey went against the DMCA's anticircumvention measures. A U.S. district court agreed, and issued an injunction shutting CHE's maintenance service (for these libraries) down.

CHE appealed the injunction, and an appeals court has now produced a ruling [PDF] reversing the injunction. In doing so, the appeals court has placed some limits, however small, on the application of the DMCA.

This case matters. It is not hard to imagine similar situations which could affect the free software community. If StorageTek's internal diagnostic streams are privileged, many other hardware communication paths may be as well. Consider a closed network adaptor, for which a free, reverse-engineered driver exists. The vendor could claim that the communications between the proprietary driver and the firmware on the card serve as an access to that (copyrighted) firmware, and that the (undocumented, complex) interface to the card is a technical measure preventing unauthorized access. By this reasoning, a free driver would be a DMCA violation. As DRM systems work their way into (what used to be) general-purpose computers, this sort of issue will come up in that context as well.

When viewed in this context, the StorageTek decision, while welcome, does not give much relief. It is a narrow decision which does little to return control of hardware to those who have purchased (and believe that they own) it.

The core of the appeals court decision is that CHE's activities did not, in fact, constitute copyright infringement. The infringement argued by StorageTek took the form of CHE loading StorageTek's maintenance code into the library's processor by means of rebooting the machine. This allegedly infringing activity is the same thing that happens when the owner of the machine turns it on. This "copying" of the software into RAM might well have been a copyright infringement, except that the copyright law contains an explicit exception for third-party maintenance providers. Even in this case, CHE might not have been in the clear, however; the company prevailed in the end because StorageTek had never made a clear separation between its operational and maintenance programs. The whole mess is loaded when the system boots, so the appeals court decided that it was all necessary to operate the library.

In other words, if StorageTek had been more careful to keep its maintenance software separate, and to not load it automatically when the system boots, it might have gotten through this appeal. The court also notes that StorageTek could have written its software license agreement to forbid third parties (such as CHE) from turning on the machine at all - but didn't.

Once that decision was reached, the court had little trouble with the DMCA claim. The DMCA, the court decided, is a copyright law. To that end, the anti-circumvention provision does not stand on its own, but is tied to the underlying copyright regime. That limits how this provision can be read:

To the extent that CHE's activities do not constitute copyright infringement or facilitate copyright infringement, StorageTek is foreclosed from maintaining an action under the DMCA.... That result follows because the DMCA must be read in the context of the Copyright Act, which balances the rights of the copyright owner against the public's interest in having appropriate access to the work.

In theory, this interpretation means that circumvention, itself, is not a crime. It is only when that circumvention is part of a violation of copyright that the DMCA comes in to play. Unfortunately, anything which is said to "facilitate" copyright infringement will fall on the wrong side of that line, so there is nothing good in this ruling for DeCSS (for example).

So, in the end, this ruling does little to enable us "consumers" to keep control over the devices that we believe we own. It is more likely to serve as a checklist for companies like StorageTek in the future: their systems are likely to be designed to avoid the pitfalls encountered by StorageTek in this case. This ruling has, mainly, increased the number of lawyers that hardware manufacturers must apply to achieve their aftermarket goals.

Whenever one buys a device containing proprietary software, one must accept that said device may serve somebody else's interests. That is in the nature of proprietary software, but that nature is made worse by current copyright law, which sees the act of paging software into RAM to execute it as an act of copying which may be controlled by the copyright owner. The ruling in the StorageTek case has drawn some boundaries on how far vendors can use copyright law to assert control over hardware they have sold, but the situation, fundamentally, has not changed.

Comments (14 posted)

Writers wanted

For the last couple of years, Joe 'Zonker' Brockmeier's articles have been a regular feature here at LWN. We are thus sad to announce that this week's article (on the Distributions Page) will be Zonker's last for LWN. Zonker has gotten a real job, and will no longer be available to write free-lance articles. We offer Zonker our thanks for many great articles, and wish him well at his new place of employment.

LWN is always looking for good writers, but, for obvious reasons, our level of interest has just gone up. We are, in particular, interested in talking to authors who have top-notch writing skills, are good at meeting deadlines, can generate ideas for articles, are not afraid of fussy editors, and who are not afraid of some of the most demanding readers around. We do pay for articles, though we must say that working for LWN is not a way for anybody to get rich.

If you think you might be interested in writing for LWN, please start by taking at a look at our author guide. Then drop us a note at authors@lwn.net and we'll talk.

Comments (7 posted)

Page editor: Jonathan Corbet

Security

Banner ads: worse than you thought

As seen on the interesting-people list: a Firefox (on Windows) user visits a "mainstream" web site, then finds a bit of malware running on his system, trying to phone home. The problem this time around was not the web site itself; instead, the unpleasant code was contained within an image being served as a banner advertisement. Many ad networks claim to be able to deliver readers, but one does not normally understand them to bring the users' systems along as well.

Over the last few years, there has been a long and tiresome series of buffer overflow vulnerabilities in the libraries which interpret various image formats. Often, the associated updates are widespread, needing to update several packages which use the affected libraries. Closing these vulnerabilities may seem like a pointless exercise; we may not expect to be attacked by way of an image file. But applications like web browsers and instant messaging clients do accept images from unknown sources, and that makes them vulnerable to attack. Even some CD players will grab and display images (CD covers) from the net. If an image library is vulnerable, the software which uses that library is vulnerable, and there can be no doubt that, where a vulnerability exists, certain people will be there to exploit it.

Advertising networks look like an especially effective means for the dispersal of malicious images. Even if every company which serves advertisements were diligent in checking all images for malware (unlikely), detecting all exploits would be a challenge. Meanwhile, a widespread ad network can distribute images from no end of web sites, most of which are unlikely to be compromised in more straightforward ways. The person reporting this particular episode noted that The Onion's site was one of those distributing malicious images; The Onion may have a stranger than normal sense of humor, but it does not extend to practical jokes of this nature.

One hopes that the image-handling libraries will get more secure over time. One may not be so naive as to hope that more complex things, such as Flash, will also improve, but a Flash-free browser generally yields a better web experience anyway. Meanwhile, it is well to remember that any path which allows data into our systems may be used against us, and advertising networks are a path with true strangers at the other end. Online ads are obnoxious enough as it is; if they become known for carrying malware, even more people will likely find themselves motivated to block ads altogether.

Comments (13 posted)

New vulnerabilities

apache2: CGI script denial of service

Package(s):

apache2

CVE #(s):

Created:

August 25, 2005

Updated:

August 31, 2005

Description:

Apache 2 has a vulnerability in which a remote attacker can access certain CGI scripts, causing exhaustion of all RAM and a denial of service.

Alerts:

Gentoo

200508-15

2005-08-25

LWN.net Weekly Edition for September 1, 2005

apache2: CGI script denial of service

backup-manager: insecure permissions and tempfile

courier: DNS failure vulnerability

libpam-ldap: authentication bypass

maildrop: missing privilege release

ntp: uses wrong gid

phpldapadmin: programming error

simpleproxy: format string vulnerability

a2ps: input validation error

affix: two remote vulnerabilities

httpd: off-by-one overflow and cross-site scripting

awstats: command injection vulnerability

bluez: command execution

bzip2: race condition and infinite loop

cpio: directory traversal

CUPS: multiple vulnerabilities

cvs: insecure temp file

cyrus-imapd: buffer overflows

dbus: information disclosure

dhcpcd: denial of service

elm: buffer overflow

emacs21: format string vulnerability in "movemail"

enscript: arbitrary code execution

epiphany: Mozilla regression vulnerability

ethereal: dissector vulnerabilities

evolution: format string issues

Foomatic: Arbitrary command execution in foomatic-rip

gaim: buffer overflow

gdb: multiple vulnerabilities

gtk-pixbuf, gtk2: denial of service

gedit: format string vulnerability

gettext: Insecure temporary file handling

ghostscript: symlink vulnerabilities

glibc: tempfile vulnerability in catchsegv script

grip: buffer overflow

groff: insecure temporary directory

gzip: arbitrary command execution

htdig: cross site scripting

imap: buffer overflow in c-client

imlib2: buffer overflows

junkbuster: heap corruption and settings modification

kdeedu: tempfile handling vulnerabilities

kdelibs: kate backup file permission leak

kernel: ELF loader core dump vulnerability

kernel: multiple vulnerabilities

kernel: multiple vulnerabilities

kernel: multiple vulnerabilities

Kismet: multiple vulnerabilities

krb5: double-free flaw

libconvert-uulib-perl: arbitrary code execution

libdbi-perl: insecure temporary file

libgadu: memory alignment bug

libgd2: buffer overflows in PNG handling

libnet-ssleay-perl: weakened cryptographic operations

libTIFF: buffer overflow

libxml2 - arbitrary code execution

libxml2: multiple buffer overflows

libXpm: new buffer overflows

lm-sensors: insecure temp files

mantis: missing input sanitizing

mod_python: remote access vulnerability

Mozilla: frame injection spoofing

mysql: low-impact security fix

ncpfs: multiple vulnerabilities

nfs-utils: arbitrary code execution

OpenSSL: information leak

OpenSSL: denial of service vulnerabilities

openvpn: multiple vulnerabilities

pam_ldap: plain text authentication leak

pcre3: arbitrary code execution

perl: setuid vulnerabilities

perl: symlink vulnerability

php: arbitrary code execution

phpsysinfo: cross-site-scripting

postgresql: database initialization errors

Pound: buffer overflow

ProFTPD: format string vulnerabilities

pstotext: remote execution of arbitrary code

rp-pppoe, pppoe: missing privilege dropping