Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop.
LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||
LWN.net Weekly Edition for August 4, 2005Wiring DRM into the system An interesting bit of corporate research was recently performed by the EFF's Seth Schoen, who attended the Microsoft Windows Hardware Engineering Conference and wrote up a four-part report on what he learned (part 1, part 2, part 3, and part 4). The resulting picture suggests that Microsoft is going out of its way to appease the entertainment industry with its future products. Upcoming Windows releases will be able to ensure that no "unauthorized" hardware or software exists on the system. Load an application which the "protected media path" code does not like, and much of the system's multimedia capability could be shut down. A Microsoft-controlled "revocation list" will allow drivers to be disabled by Microsoft in the future should those drivers be determined to not properly implement the DRM specifications. Overall, it is a vision of a world where "our" computers are, increasingly, not under our control and not operating in our interests.The comments on the original LWN posting pointing to Seth's reports suggest that many readers believe that this sort of intrusive DRM technology will provoke a massive consumer backlash and, as a result, fail in the market. There are some signs that this hope could be realized; there is currently a fair amount of grumbling in the U.S. over the HDCP copy-protection mechanism, which can prevent the delivery of high-resolution video to large numbers of high-definition TV monitors which do not implement HDCP. As others have often said: Americans will put up with all sorts of misbehavior from both governments and corporations, but they will not tolerate anybody who messes with their TV. All of this may be wishful thinking, however. It may well be that the industry will get its DRM technology working to the point that it no longer interferes greatly with the life of the average couch potato. If things "just work" for most people, they will be accepted by those people. Few of us have the time or knowledge to worry about the larger issues of fair use, control over our own systems, or long-term sustainability of the cultural commons. After all, there's a game on in a few minutes. Consider also the reports that Apple is planning to make use of the trusted platform module (TPM) chip in its future kernels. The primary purpose here, most likely, is to keep people from running Mac OS on non-approved x86 systems. But it is hard to believe that Apple would not also use the TPM, for example, to help ensure that audio files do not escape from the one system where they are authorized to be. Then consider that the latest Linux kernel includes basic TPM support, and work is underway to increase that support. As was discussed at the Ottawa Linux Symposium, the TPM can do a number of good things for Linux users. It can also, however, be used to deprive a Linux user of control over the system and implement all of the same DRM stuff which is being added elsewhere. A Linux-based set-top box could be just as user-hostile as one based on Windows. Availability of source would not be helpful in such a situation; the TPM can be used to ensure that the system will boot only kernels which have been signed with a specific key. Linus Torvalds has stated in the past that this sort of usage is fine with him. Now, Linus is not the only copyright holder for the kernel, and others may yet decide that the GPL requires that the keys used to sign the kernel be distributed with the source. The GPL's source distribution requirements do include "the scripts used to control compilation and installation of the executable," after all. It may even be that a court will buy that argument. But any such finding will be at the far end of a long process of litigation; it is an uncertain and distant prospect. In the mean time, it is safe to assume that we will see more systems which, while running Linux, allow no more user control than their equivalents based on proprietary software. At OLS, Jim Gettys compared the DRM situation to the American experiment with crypto export regulations. We'll win in the end, but there may be a decade or two of pain in the middle. Sadly, it appears that we are just beginning to enter the "pain" phase of this battle. This is a fight we can win; we will likely be helped by the fact that the entertainment industry will have a hard time stopping short of the point that makes consumers rebel. But there may indeed be some unpleasant times between here and there.
Cisco v. full disclosure The story has been sufficiently widely reported that we do not need to go into the details here; see Bruce Schneier's summary if you have some catching up to do. In short: Cisco is going after ex-ISS employee Michael Lynn after he made a presentation in Las Vegas on security vulnerabilities in Cisco's IOS. There is now an FBI investigation in the works, and Mr. Lynn faces the possibility of lawsuits from Cisco or ISS (or both). Meanwhile, copies of his presentation are circulating on the net, closely followed by lawyers with takedown notices. BoingBoing has posted a list of mirrors for those of you who have not yet gotten your copy.Cisco's argument is that Mr. Lynn's presentation discloses Cisco's trade secrets. By this reasoning, Cisco's customers are not entitled to know about vulnerabilities in the boxes they have used to put their networks together. In fact, it appears that Cisco has known about this vulnerability since April, but did not see fit to tell its customers - or anybody else - about it until after Mr. Lynn's presentation. Cisco's concern for its public image has clearly outweighed its concern for its customers' security. The company has turned against disclosure of security problems, and also seems to have forgotten what the net has taught us over the last twenty years or so: attempting to suppress information which has escaped onto the net is not only futile, but it increases the distribution of that information. There is another aspect of this situation which is worth looking at, however. It has often been said that users of embedded systems do not care about which operating system is running inside. The system is invisible, and all that matters is that it does its job. Security problems clearly increase the visibility of an embedded system. But so do trade secrets, and in an unpleasant way. If Cisco's routers ran Linux, there would be no question of the company using trade secrets to shut down disclosure of vulnerabilities in the core system. There cannot be trade secrets embedded within GPL-licensed code - at least, any such secrets will not remain secret for long. So an attempt to use trade secrets to block disclosure of a security problem is almost certain to fail. This is a good thing, and a nice added benefit from the use of free software. People may not care about the code running inside their router, phone, music player, automobile, or Furby, but they may yet learn to care about having vulnerabilities in those devices hidden from them. Among the many promises carried by free software is this one: it does not contain secrets which may be used to censor those who would tell you about a problem with your gadget. That is a worthwhile freedom.
Our bloat problem Andy Oram's report from the Ottawa Linux Symposium notes that OpenOffice.org took some grief there:
Already, two speakers have made wisecracks about OpenOffice.org,
tagging it as a bloated memory hog. I have the suspicion that some
attendees see Linux as something to run for its own intrinsic
value, rather than as a platform for useful applications that can
actually help people accomplish something.
As one of those speakers, your editor will plead guilty to taking a cheap shot for an easy laugh (and people did laugh). But the remark had nothing to do with the value of OpenOffice.org as an application. It was about bloat. In a private conversation at the same conference, an engineer working with a services company in a developing country mentioned a valuable line of business for his employer. It seems that there are customers with large numbers of older desktop computers running legacy operating systems; they would like to extend the life of those computers by putting Linux onto them. But Linux does not run as well on these systems as anybody would like; it is simply too big. OpenOffice.org is especially problematic on smaller systems, but the problem does not stop there. Not that long ago, Linux was a relatively small and fast system which could run well on a wide variety of older hardware. That may still be true in some specific cases - Linux-based firewall/routers, for example - but, as a general-purpose operating system, Linux has become just as bloated as its proprietary competition. Your editor just looked at his desktop system, with two days of uptime, to see where the memory went. A few examples:
It is a sad world when 10MB of memory is required to display a clock, and 21MB to run a terminal emulator. Developers who have taken a class in data structures have probably heard all about time-space tradeoffs. Programs can often be made faster at the expense of higher memory usage. The truth of the matter, however, is that these tradeoffs are often illusory. Big code is slow code. From inferior processor cache usage through to virtual memory thrashing, large code slows things down across the entire system. On contemporary systems, the way to faster code is often by using less space, not more. There are signs that more developers are beginning to understand the costs of bloat. There is a GNOME memory reduction project underway, for example, though it does not appear to be progressing rapidly. But a more serious effort will be required if the Linux desktop is going to lose some significant weight. And it should lose that weight. Some growth is to be expected from the development of the software itself - Linux systems can do much more than they could a few years ago. But it seems clear that much of our development has been aimed at the addition of new features, and relatively little attention has been paid to memory usage. At this point, Linux need not feel insecure about the features it offers; maybe the time has come to put some more effort into implementing those features with fewer resources. Otherwise, Linux is inflating itself out of a number of possible applications and losing the leanness which used to be one of its best attributes.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||||||||||||