LWN.net Weekly Edition for September 12, 2013

Toward healthy paranoia

Some of the recent leaks have made it clear that the NSA has worked actively to insert weaknesses into both cryptographic standards and products sold by vendors. There is, for example, some evidence that the NSA has inserted weaknesses into some random-number generation standards, to the point that the US National Institute of Standards and Technology has felt the need to reopen the public comment period for the 800-90A/B/C random number standards, in which there is little confidence at this point. While no compromised commercial products have yet been named, it seems increasingly clear that such products must exist.

It is tempting to believe that the inherent protections that come with free software — open development processes and code review — can protect us from this kind of attack. And to an extent, that must be true. But it behooves us to remember just how extensively free software is used in almost every setting from deeply embedded systems to network routers to supercomputers. How can such a software system not be a target for those bent on increasing the surveillance state? Given the resources available to those who would compromise our systems, how good are our defenses?

In that context, this warning from Poul-Henning Kamp is worth reading:

Given the potential payoff from the insertion of a vulnerability into a widely used free software project, it seems inevitable that attempts have been made to do just that. And, it should be noted, the NSA is far from the only agency that would have an interest in compromising free software. There is no shortage of well-funded intelligence agencies worldwide, many of which operate with even less oversight than the NSA does. Even if the NSA has never caused the submission of a suspect patch to a free software project, some other agency almost certainly has.

Some concerns about this kind of compromise have already been expressed; see the various discussions (example) about the use of Intel's RDRAND instruction to add entropy to the kernel's pool of random data, for example (see also Linus responding to those concerns in typical Linus style). This lengthy Google+ discussion on random-number generation is worth reading; along with a lot of details on how that process works, it covers other concerns — like whether the NSA has forced companies like Red Hat to put backdoors into their Linux distributions. As people think through the implications of all that has been going on, expect a lot more questions to be raised about the security of our software.

Predicting an increased level of concern about security is easy; figuring out how to respond is rather harder. Perhaps the best advice comes from The Hitchhiker's Guide to the Galaxy: don't panic. Beyond anything else, we need to resist any temptation to engage in witch hunts. While it is entirely possible that somebody — perhaps even a trusted community figure — has deliberately inserted a vulnerability into a free software project, the simple truth remains that most bugs are simply bugs. If developers start to come under suspicion for having made a mistake, we could find ourselves driving some of our best contributors out of the community, leaving us weaker than before.

That said, we do need to start looking at our code more closely. We have a huge attack surface — everything from the kernel to libraries to network service daemons to applications like web browsers — and, with no external assistance at all, we succeed in adding far too many security bugs across that entire surface. There is clearly a market for the location and exploitation of those bugs, and there is quite a bit of evidence that governments are major buyers in that market. It is time that we got better at reviewing our code and reduced the supply of raw materials to the market for exploitable vulnerabilities.

Much of our existing code base needs to be looked at again, and quite a bit of it is past due for replacement. The OpenSSL code is an obvious target, for example; it is also widely held to be incomprehensible and unmaintainable, making auditing it for security problems that much harder. There are projects out there that are intended to replace OpenSSL (see Selene, for example), but the job is not trivial. Projects like this could really use more attention, more contributors, and more auditors.

Another challenge is the proliferation of systems running old software. Enterprise Linux distributions are at least supported with security updates, but old, undisclosed vulnerabilities can persist there for a long time. Old handsets (for values of "old" that are often less than one year) that no longer receive updates are nearly impossible to fix. Far worse, though, are the millions of old Linux-based routers. Those devices tend to be deployed and forgotten about; there is usually no mechanism for distributing updates even if the owners are aware of the need to apply them. Even projects like OpenWRT tend to ignore the security update problem. Given that spy agencies are understandably interested in attacking routers, we should really be paying more attention to the security of this kind of system.

While many in the community have long believed that a great deal of surveillance was going on, the current revelations have still proved to be shocking, and they have severely undermined trust in our communications systems. Future disclosures, including, one might predict, disclosures of activities by agencies that are in no way allied with the US, will make the problem even worse. The degree of corporate collaboration in this activity is not yet understood, but even now there is, unsurprisingly, a great deal of suspicion that closed security-relevant products may have been compromised. There is not a lot of reason to trust what vendors are saying (or not saying) about their products at this point.

This setting provides a great opportunity for free software to further establish itself as a secure alternative. The maker of a closed product can never effectively respond to suspicions about that product's integrity; free software, at least, can be inspected for vulnerabilities. But to take advantage of this opening, and, incidentally, help to make the world a more free place, we need to ensure that we have our own act together. And that may well require that we find a way to become a bit more paranoid while not wrecking the openness that makes our communities work.

Comments (77 posted)

Intel and XMir

Reverting a patch, at least one that isn't causing a bug or regression, is often controversial. Normally, the patch has been technically vetted before it was merged, so there is—or can be—a non-technical reason behind its removal. That is the case with the recent reversion of a patch to add XMir support to the Intel video driver. As might be guessed, rejecting support for the X compatibility layer of the Mir display server resulted in a loud hue and cry—with conspiracy theories aplenty.

The patch adding support for XMir was merged into the xf86-video-intel driver tree on September 4 by maintainer Chris Wilson. That driver is the user-space X.org code for supporting Intel GPUs; it is code that Intel has developed and maintains. The commit message noted that the XMir API had likely been frozen so support for the API was being added to the driver. The patch consists of less than 300 lines of code, most of it confined to a new sna_xmir.c file. Based on the commit and message, Wilson clearly didn't see any reason not to merge the patch.

All of that changed sometime before the revert on September 7, which also prompted the release of the 2.99.902 snapshot. In the NEWS file for the snapshot was the following message:

There are a number of possible interpretations for that statement, but, however it was meant, it was certain to raise the ire of Canonical and/or Mir fans—and it did. When asked about the removal of XMir support, Wilson pointed to Intel management for answers. I contacted Dirk Hohndel, CTO of the Intel Open Source Technology Center, who answered the main question at hand: Intel's "engineering team and the senior technical people made the decision that we needed to continue to focus our efforts on X and Wayland", he said. It was a question of focus, he said, "adding more targets to our QA and validations needs, having to check more environments for regressions [...] would require us to cut somewhere else".

So removing support for XMir was requested by Intel management, but seemingly did not sit very well with Wilson. One suspects the NEWS file entry did not get approved, for example. But it's hard to see that any reversion (or outright rejection) of the XMir support would have led to a different outcome. Ubuntu has a legion of fans, who can often be quite vocal when they believe their distribution is being treated unfairly.

Michael Hall, a Canonical employee on the Community team, obliquely referenced the XMir removal in a post to Google+: "You will not make your open source project better by pulling another open source project down." The argument that Hall and others make is that because Intel supports Wayland, it is hamstringing Mir by removing support for it, and, in effect, helping to keep Mir as a single-distribution display server. "This just strikes me as trying to win the race by tripping the competition, not by running faster", Hall said in the comments.

But accepting any code into a codebase you maintain is a burden at some level. Supporting a new component, like a display server, also requires a certain amount of testing. All of those things need to be weighed before taking on that maintenance. As Matthew Garrett put it (also in the comments to Hall's post):

Certainly Canonical can continue to carry the XMir patches for the Intel video driver. It is, after all, carrying its own display server code in addition to its Unity user interface and various other Ubuntu-specific components. But Hall sees the "single-distribution solution" as a self-fulfilling prophecy:

Since its initial attempt—with less than stellar results—Canonical has not really tried to make any kind of compelling technical arguments about Mir's superiority or why any other distribution (or desktop environment) would want to spend time working on it (as opposed to, say, Wayland). The whole idea is to have a display server that serves Unity's needs and will run on multiple form factors in a time frame that Canonical requires. That's not much of an argument for other projects to jump on board. As Garrett points out, Canonical has instead chosen the route of "winning in the market", which is going to require that it shoulder most or all of the burden until that win becomes apparent. Casting the rejection of XMir as an attack of some kind is not sensible, Garrett said:

Other comment threads (for example on Reddit here and here) followed a similar pattern. Intel focusing on Wayland and X is seen as Mir (or Canonical) bashing, with some positing that it really was an attempt to prop up Tizen vs. Ubuntu Touch (or some other Canonical mobile initiative). Or that Intel believes Wayland is so badly broken it needs to stop the Mir "momentum" any way it can. Most of that seems fairly far-fetched.

One can understand Intel's lack of interest in maintaining support for XMir without resorting to convoluted reasons—though the size of the patch and how self-contained it is do lead some to wonder a bit. There is a risk for Intel in doing so, however. As Luc Verhaegen, developer of the Lima driver for ARM Mali GPUs, pointed out in a highly critical blog post, Intel could actually end up harming its own interests:

At this point, though, Intel may well be waiting to see the "proof of the pudding". If Canonical is successful at getting Mir onto the desktops of lots of Intel customers in the next year or two, one suspects that any needed changes for Mir or XMir will be cheerfully added to the Intel video driver. For now, the company loses little, and gains some maintenance and testing time, by waiting for it all to play out.

In the end, there is an element of a "tempest in a teapot" to the whole affair. We are talking about 300 lines of code that, evidently, won't need much in the way of changes in the future (since the API is frozen). Intel is almost certainly embarrassed by how the whole thing played out, and Ubuntu fans will undoubtedly see it as yet another diss of their favorite distribution. But in the final analysis, the impact on Mir users will be minimal to non-existent, at least in the short term and probably the long as well.

Comments (155 posted)

Page editor: Jonathan Corbet

Security

Using vulnerabilities instead of new laws

A paper presented at the Privacy Law Scholars Conference in June asks an interesting question: what are the implications of allowing law enforcement to use existing vulnerabilities to wiretap the internet? In some sense, current events have outrun the paper's focus as we now know that the NSA has been using vulnerabilities in its quest for every last bit of internet traffic, but there are legitimate questions raised by the paper. If, someday, the US returns to the idea of actual oversight of domestic (at least) internet surveillance, it will be worth considering the tradeoffs described in the paper.

The paper starts by pointing out that critics of the Communications Assistance for Law Enforcement Act (CALEA), which mandated wiretap-friendly interfaces for telephony equipment, were fully justified by later events. Those interfaces were illegally used in a number of different ways, including wiretapping a large number of Greek politicians in 2005. Extending CALEA to the internet, which is something the FBI has been advocating, will predictably lead to similar abuses, so it is worthwhile to look at alternatives.

The authors, Steven M. Bellovin, Matt Blaze, Sandy Clark, and Susan Landau, instead propose that the FBI be authorized to use existing vulnerabilities for wiretapping. Rather than requiring vendors to insert vulnerabilities into their code so that the FBI can wiretap voice-over-IP (VoIP) and other communications, just recognize that there are already vulnerabilities available that allow the required access. But, there are a number of consequences—along with ethical questions—that stem from allowing that behavior.

The wide-ranging paper covers a lot of ground. Some of the more interesting technical discussion has to do with vulnerabilities themselves. The authors' argument, essentially, is that there will always be vulnerabilities available that will allow the capabilities needed by law enforcement. It is simply a matter of finding or obtaining them, then using them against the target for whom a warrant has been issued. Even if a CALEA-style law were passed for internet communications, they argue, there would still be a need for vulnerability-based wiretapping. There is existing software that doesn't implement the interfaces and targets may be using end-to-end encryption, for example.

But in order to gain access to the "right" vulnerabilities for the target (which would need to be determined by some kind of "technical reconnaissance"), the FBI would need to access the vulnerability "black market". Since the goal of wiretapping is different than that of typical attackers, any exploit would likely need to be modified to have a "wiretapping payload" rather than the usual spambot, remote-access, or credential-stealing payloads. There is, in short, quite a bit of work that would need to be done before bits of VoIP data start flowing to the cops. From what we know now, it would be far easier to just ask the NSA.

But, assuming the NSA option closes down at some point, the ethical dilemmas surrounding this whole idea still pose some significant hurdles. For example, if the FBI knows about a highly useful vulnerability that is also being exploited by botnet herders or other criminals, will it report the hole? Or if a company is about to release an update that closes a hole being actively used, will pressure be applied to delay (or subvert) the release? How does the FBI ensure that its wiretapping tools aren't disseminated to the underworld? There are, of course, plenty more questions beyond just those.

Overall, it is an interesting quandary. On the one hand, routing around a "CALEA for the internet" is certainly attractive. The harm to both innovation and privacy that could be caused by such legislation is huge. On the other hand, though, turning the FBI and other law enforcement organizations into players on the malware stage has its own set of dangers. The authors conclude that those dangers (or "uncomfortable issues" as they call them) are less of a concern than the legislative solution. Unfortunately for all of us, legislators and law enforcement rarely grasp the idea that there might be solutions outside of new laws. In fact, the NSA revelations may have shown an entirely different way to operate without any new laws.

Comments (12 posted)

Brief items

Security quotes of the week

Comments (19 posted)

Roeckx: State of encryption

Comments (21 posted)

New vulnerabilities

exactimage: denial of service

Comments (none posted)

fedora-business-cards: insecure temporary file usage

Comments (none posted)

gdm: privilege escalation

Comments (none posted)

kernel: code execution

Comments (none posted)

kernel: denial of service

Comments (none posted)

LibRaw: denial of service

Comments (none posted)

phpbb3: file overwrites

Comments (none posted)

python-django: directory traversal

Comments (none posted)

subversion: privilege escalation

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

Stable updates: 3.10.11, 3.4.61, and 3.0.95 were all released on September 7; 3.2.51 came out on September 11.

Comments (none posted)

Quotes of the week

	rcu_is_cpu_idle() # reversed sense from the others
	rcu_is_ignored() # reversed sense from the others
	rcu_is_not_active() # reversed sense from the others
	rcu_is_watching_cpu()
	rcu_read_check()
	rcu_is_active()
	rcu_is_active_local()
	rcu_is_online()
	rcu_is_watching_task()
	rcu_is_watching_thread()
	rcu_is_watching_you()
	all_your_base_are_belong_to_rcu()
	rcu_is_active_loco()
	rcu_kilroy_was_here()

Comments (1 posted)

Kernel development news

3.12 merge window, part 2

This development cycle continues to feature a large range of internal improvements and relatively few exciting new features. Some of the user-visible changes that have been merged include:

• The direct rendering graphics layer has gained the concept of "render nodes," which separate the rendering of graphics from modesetting and other display control; the "big three" graphics drivers all support this concept. See this post from David Herrmann for more information on where this work is going.

• The netfilter subsystem supports a new "SYNPROXY" target that simulates connection establishment on one side of the firewall before actually establishing the connection on the other. It can be thought of as a way of implementing SYN cookies at the perimeter, preventing spurious connection attempts from traversing the firewall.

• The TSO sizing patches and FQ scheduler have been merged. TSO sizing helps to eliminate bursty traffic when TCP segmentation offload is being used, while FQ provides a simple fair-queuing discipline for traffic transiting through the system.

• The ext3 filesystem has a new journal_path= mount option that allows the specification of an external journal's location using a device path name.

• The Tile architecture has gained support for ftrace, kprobes, and full kernel preemption. Also, support for the old TILE64 CPU has been removed.

• The xfs filesystem is finally able to support user namespaces. The addition of this support should make it easier for distributors to enable the user namespace feature, should they feel at ease with the security implications of such a move.

• Mainline support for ARM "big.LITTLE" systems is getting closer; 3.12 will include a new cpuidle driver that builds on the multi-cluster power management patches to provide CPU idle support on big.LITTLE systems.

• The MD RAID5 implementation is now multithreaded, increasing its maximum I/O rates when dealing with fast drives.

• The device mapper has a new statistics module that can track I/O activity over a range of blocks on a DM device. See Documentation/device-mapper/statistics.txt for details.

• The device tree code now feeds the entire flattened device tree text into the random number pool in an attempt to increase the amount of entropy available at early boot. It is not clear at this point how much benefit is gained, since device trees are mostly or entirely identical for a given class of device. It is possible for a device tree to hold unique data — network MAC addresses, for example — but that is not guaranteed, and some developers think that entropy would be better served by just feeding the unique data directly.

• New hardware support includes:
  • Systems and processors: Freescale P1023 RDB and C293PCIE boards.

  • Graphics: Qualcomm MSM/Snapdragon GPUs. The nouveau graphics driver has also gained proper power management support, and the power management support for Radeon devices has been improved and extended to a wider range of chips.

  • Miscellaneous: GPIO-controlled backlights, Sanyo LV5207LP backlight controllers, Rohm BD6107 backlight controllers, IdeaPad laptop slidebars, Toumaz Xenif TZ1090 GPIO controllers, Kontron ETX/COMexpress GPIO controllers, Fintek F71882FG and F71889F GPIO controllers, Dialog Semiconductor DA9063 PMICs, Samsung S2MPS11 crystal oscillator clocks, Hisilicon K3 DMA controllers, Renesas R-Car HPB DMA controllers, and TI BQ24190 and TWL4030 battery charger controllers.

  • Networking: MOXA ART (RTL8201CP) Ethernet interfaces, Solarflare SFC9100 interfaces, and CoreChip-sz SR9700-based Ethernet devices.

  • Video4Linux: Renesas VSP1 video processing engines, Renesas R-Car video input devices, Mirics MSi3101 software-defined radio dongles (the first SDR device supported by the mainline kernel), Syntek STK1135 USB cameras, Analog Devices ADV7842 video decoders, and Analog Devices ADV7511 video encoders.

Changes visible to kernel developers include:

• The GEM and TTM memory managers within the graphics subsystem are now using a unified subsystem for the management of virtual memory areas, eliminating some duplicated functionality.

• The new lockref mechanism can now mark a reference-counted item as being "dead." The separate state is needed because lockrefs can be used in places (like the dentry cache) where an item can have a reference count of zero and still be alive and usable. Once the structure has been marked as dead, though, the reference count cannot be incremented and the structure cannot be used.

The closing of the merge window still looks to happen on September 15, or, perhaps, one day later to allow Linus to get back up to speed after his planned weekend diving experience.

Comments (7 posted)

Opening up kernel security bug handling

The reporting and handling of security issues is a tricky proposition. There are numerous competing interests to try to balance, and a general tendency toward secrecy that can complicate things further. Thus it is not surprising that kernel developers are discussing security handling on the Kernel Summit discussion mailing list (ksummit-2013-discuss). It seems likely that discussion will pick up again at the summit itself, which will be held in Edinburgh, October 23-25.

James Bottomley kicked off the discussion by noting that several recent fixes had gone into the kernel without following the normal process because they were "security fixes". Given that some of those fixes caused problems of various sorts, he is concerned about circumventing the process simply because the patches fix security issues:

Bottomley would like to explore whether security vulnerabilities need to be handled in secret at all. Given that he thinks that may not be popular, looking into what can be done to inject more transparency into the process would be a reasonable alternative. Part of his theory is that "security people" who "love secrecy" are running the vulnerability-handling process.

For example, the closed kernel security mailing list (security@kernel.org) is either made up of "security officers" (according to Documentation/SecurityBugs) or "'normal' kernel developers" (according to Greg Kroah-Hartman). There is no inherent interest in secrecy by the participants on that list, Kroah-Hartman said, though he did agree that posting a list of the members of security@kernel.org—which has not yet happened—would help to make things more transparent. The relationship between the kernel security list and the linux-distros mailing list (a closed list for distribution security concerns—the successor to vendor-sec) is also a bit murky, which could use some clearing up, Bottomley said.

A big part of the problem is that there are a few different constituencies to try to satisfy, including distributions (some of which, like enterprise distributions, may have additional needs or wants), users (most of whom get their kernel from a distributor or device maker), security researchers (who sometimes like to make a big splash with their findings), and so on. While it might be tempting to dismiss the security researchers as perpetrators of what Linus Torvalds likes to call "the security circus", it is important to include them. They are often the ones who find vulnerabilities; annoying them often results in them failing to report what they find, sadly.

Secrecy in vulnerability handling may be important to the enterprise distributions for other reasons, as Stephen Hemminger said. Security vulnerabilities and response time are often used as a "sales" tool in those markets, so that may lead to a push for more secrecy:

Torvalds's practice of hiding the security implications of patches also plays a role here. He wants to mask vulnerabilities so that "black hats" cannot easily grep them from commit logs, but as James Morris pointed out, that's not really effective: "The cryptic / silent fixes are really only helping the bad guys. They are watching these commits and doing security analysis on them."

It seems unlikely (though perhaps not completely impossible) that Torvalds would change his mind on the issue, so various ideas on collecting known security information correlated with the commit(s) that fixed them were batted around. Clearly, some information about security implications only comes to light after the commit has been made—sometimes long after—so there is a need to collect it separately in any case.

Kees Cook described some of the information that could be collected, while Andy Lutomirski expanded on the idea by suggesting separate CVE files stored in the kernel tree. The idea seemed fairly popular; others chimed in with suggestions for collaborating with Debian and/or the linux-distros mailing list participants. In a separate sub-thread, Lutomirski created a template for how the information could be stored. Cook concurred and suggested that the files could live under Documentation/CVEs or something similar. It is clear that there is an interest in having more data available on security vulnerabilities and fixes in the kernel, so that could lead to a lively discussion in October.

Some seem to have already started down the path of more openness in the security reporting realm. Lutomirski recently publicly posted a fix that was clearly marked as a security fix from the outset. Cook did much the same with a list of vulnerabilities in the kernel's human interface device (HID) code. Exploiting the HID bugs requires physical access and specialized devices, but that may be part of the threat model for certain users. These aren't the first reports of this kind; others have been made from time to time. In fact, certain subsystems (networking, in particular) essentially never use the closed list and prefer to work on security problems and fixes in the open.

An even more recent example comes from Wannes Rombouts's report of a networking security hole (use after free), which was referred to the netdev mailing list by security@kernel.org. The implications of the bug were not completely clear (either to Rombouts or to Hemminger, who replied), but Ben Hutchings recognized that user namespaces could make the problem more widespread (when and if they are enabled in most kernels anyway). Though it is networking related—thus the referral to netdev, presumably—this is the kind of vulnerability that could have been handled behind closed doors. But because it was posted to an open list, the full implications of the problem were discovered. In addition, for this bug (as well as for Lutomirski's and Cook's bugs), those affected have the ability to find out about the problems and either patch their kernels or otherwise mitigate the problem. And that is another advantage of openness.

Comments (12 posted)

BSD-style securelevel comes to Linux — again

By Matthew Garrett's reading of the secure boot requirements, a system running in secure boot mode must not allow any user to change the running kernel; not even root is empowered to do so. Just over one year ago, Matthew posted a set of patches that implemented the necessary restrictions. In secure boot mode (as defined by the absence of a new capability called, at that time, CAP_SECURE_FIRMWARE), the kernel would not allow the loading of unsigned kernel modules, direct access to I/O ports or I/O memory, or, most controversially, use of the kexec_load() system call to reboot directly into a new kernel. As one might expect, not everybody liked this type of restriction, which flies in the face of the longstanding Unix tradition of giving root enough rope to shoot itself in the foot.

So there were discussions around various aspects of these patches, but one of the biggest problems only came to light later. It seems that there is a fundamental flaw in the capability model: it is nearly impossible to add new capability bits without risking problems with applications that do not know about the new bits. In particular:

• Some capability-aware applications work by turning off every capability that they do not think they need. If a new bit is added controlling functionality that such an application uses, it will unknowingly disable a necessary capability and cease to work properly. From the point of view of users of this application, this kind of change constitutes an incompatible ABI change.

• Other applications work in a blacklist-oriented mode, turning off capabilities that are known not to be needed. In essence, such an application simply sets the capability mask to zero, then sets the bits corresponding to the capabilities it wants. If some sort of security-related functionality is put behind a new bit that is unknown to this kind of application, that application will leave the capability enabled. That, in turn, could make the application insecure.

In this case, the biggest risk is that whitelist-style applications would inadvertently turn off CAP_SECURE_FIRMWARE, essentially putting themselves into secure boot mode even if the system as a whole is not running in that mode. That could cause things to break in mysterious ways. What it comes down to is that, if one is designing a capability-based system, one really must come up with the full list of needed capabilities at the outset. Back in 1998, when capabilities for Linux were being hashed out, nobody had UEFI secure boot in mind. So there is no relevant capability bit available, and adding one now is not really an option.

More recently, Matthew posted a new patch set that eliminates the new capability. Instead, all of the secure boot restrictions were tied to the existing flag controlling whether unsigned kernel modules can be loaded. Matthew's reasoning was that the restriction on module loading exists to prevent the loading of arbitrary code into the running kernel, so it made sense to lock down any other functionality that might make it possible to evade that restriction. Other developers disagreed, though, saying that they needed the ability to restrict module loading while still allowing other functionality — kexec_load() in particular — to be used normally. After some discussion, Matthew backed down and withdrew the patches.

Eventually he came back with what he called his final attempt at providing a kernel lockdown facility that wasn't tied to the secure boot mechanism itself. This time around, we have a new sysfs file at /sys/kernel/security/securelevel that accepts any of three values. If it is set to zero (the default), everything works as it always has, with no new restrictions. Setting it to one invokes "secure mode," in which all of the restrictions related to secure boot go into effect. Secure mode is also irrevocable; once it has been enabled, it cannot be disabled (short of compromising the kernel, at which point the battle is already lost). There is also an interesting "permanently insecure" mode obtained by setting securelevel to -1; the system's behavior is the same as with a setting of zero, but it is no longer possible to change the security level.

In the UEFI secure boot setting, the bootstrap code would take pains to set securelevel to one before allowing any processes to run. That helps to avoid race conditions where the system is subverted before the lockdown can be applied.

Some readers will, by now, have recognized that "securelevel" looks an awful lot like the BSD functionality that goes by the same name; it was clearly patterned after BSD's version. Amusingly, this is not the first time that securelevel has been considered for Linux; there was an extensive discussion on the subject in early 1998, when Alan Cox was pushing strongly for a securelevel feature. At that time, Linus rejected the feature because he had something much better in mind: capabilities. As is usually the case, Linus won out, and Linux got capabilities instead of securelevel.

More than fifteen years later, it seems that we might just end up with both mechanisms. Thus far, Matthew's latest patch set has not resulted in many screams of agony, so it might just pass review this time — though, at this point, it is almost certainly too late for 3.12. Meanwhile, Vivek Goyal has posted the first version of a signed kexec patch set that would limit kexec_load() to signed images. That would allow some useful features (kdump, for example) to continue to work properly in the secure boot environment without leaving kexec_load() completely open. That, too, will make the secure boot restrictions a bit more palatable and increase their chances of being merged.

Comments (35 posted)

Patches and updates

Kernel trees

• Greg KH: Linux 3.10.11 . (September 9, 2013)

• Steven Rostedt: 3.6.11.8-rt40 . (September 9, 2013)

• Greg KH: Linux 3.4.61 . (September 9, 2013)

• Ben Hutchings: Linux 3.2.51 . (September 11, 2013)

• Greg KH: Linux 3.0.95 . (September 9, 2013)

Core kernel code

• Christoph Lameter: [RFC] Restrict kernel spawning of threads to a specified set of cpus. . (September 8, 2013)

• Linus Torvalds: Adding concept of "dead" references to lockref . (September 9, 2013)

• Con Kolivas: BFS CPU scheduler v0.442 for linux-3.11 . (September 10, 2013)

• Mel Gorman: Basic scheduler support for automatic NUMA balancing V7 . (September 10, 2013)

• Peter Zijlstra: preempt_count rework -v2 . (September 10, 2013)

• Jeff Mahoney: kobject: introduce kobj_completion . (September 11, 2013)

• Zach Brown: extending splice for copy offloading . (September 11, 2013)

Development tools

• Tom Zanussi: tracing: trace event triggers . (September 9, 2013)

• John Stultz: [RFC] seqcount: Add lockdep functionality to seqcount/seqlock structures . (September 10, 2013)

Device drivers

• Xiubo Li: Add Freescale FTM PWM driver. . (September 8, 2013)

• Heiko Stübner: Input: add driver for Neonode zForce based touchscreens . (September 9, 2013)

• Lee Jones: iio: ST clean-ups and new sensor support . (September 10, 2013)

• Daniel Jeong: media: i2c: add driver for dual LED Flash, lm3560. . (September 11, 2013)

• Yadwinder Singh Brar: Add basic support for ASV . (September 11, 2013)

• Kamil Debski: [PATCH] phy: Add new Exynos USB PHY driver . (September 11, 2013)

• Mika Westerberg: runtime PM support for I2C and SPI client devices . (September 11, 2013)

Filesystems and block I/O

• Waiman Long: dcache: Translating dentry into pathname without taking rename_lock . (September 8, 2013)

• Milosz Tanski: ceph: fscache support & upstream changes . (September 8, 2013)

• Marco Stornelli: pramfs . (September 9, 2013)

• J. Bruce Fields: Implement NFSv4 delegations, take 10 . (September 10, 2013)

Memory management

• Naoya Horiguchi: split page table lock for hugepage . (September 8, 2013)

• Krzysztof Kozlowski: mm: migrate zbud pages . (September 11, 2013)

Networking

• Simon Horman: MPLS actions and matches . (September 10, 2013)

Architecture-specific

• Rohit Vaswani: ARM: msm: Add support for APQ8074 Dragonboard . (September 9, 2013)

• Preeti U Murthy: [PATCH V3 0/6] cpuidle/ppc: Enable broadcast support for deep idle states . (September 11, 2013)

Security-related

• H. Peter Anvin: random: Account for entropy loss due to overwrites . (September 9, 2013)

• Matthew Garrett: One more attempt at useful kernel lockdown . (September 9, 2013)

• Vivek Goyal: [RFC PATCH] Signed kexec support . (September 10, 2013)

Virtualization and containers

• Boris Ostrovsky: xen/PMU: PMU support for Xen PV guests . (September 10, 2013)

Miscellaneous

• Mathieu Desnoyers: Userspace RCU 0.7.8 . (September 8, 2013)

• Hans de Goede: Announcing libusbx-1.0.17 final . (September 10, 2013)

Page editor: Jonathan Corbet

Distributions

Debian gets dgit

It is pretty easy to get a new project up and running with Git, but integrating Git—or any other new version control system—can be painful for an existing project with an established code base. Such is the case for Debian, with its tens of thousands of packages spread across multiple versions of the distribution. Migrating Debian to a Git-based version-control system would be a herculean ordeal, if that was even a task that the project was interested in undertaking. But Ian Jackson recently unveiled a new tool that serves as a bridge between the official Debian archives and a Git repository, thus allowing developers to use a Git workflow while remaining fully integrated with the archive.

The tool is called dgit; Jackson announced version 0.7, the first "suitable for alpha and beta testers", on August 22. The concept behind it was hashed out during DebConf13 in mid-August. As Jackson explained it, the goal was to allow package maintainers and developers to use "a gitish workflow" if they so desired, including working with upstream Git repositories and preserving Git histories, but without forcing a Git-based workflow on anyone who was happier using the status quo.

The bird's-eye view of dgit is that it treats the Debian archive (which contains all of the packages that make up a Debian release) as if it were a remote Git repository. A developer can clone or fetch a package from the archive, commit and merge changes, and push updates to the package, all using dgit commands that mirror, in most ways, the offerings of Git itself. But this functionality is on demand; if no developer dgit clones a particular package, there is no Git view of it created—doing so automatically for every Debian package would consume far too many resources.

Thus, there is quite a bit of work going on behind the scenes to keep the archive and the dgit view of the package in sync. When a developer uses:

    dgit clone foopackage sid

for example, dgit initializes a Git repository on Debian's Alioth server, pulls in the contents of foopackage from the sid distribution, then constructs the local repository on the developer's machine. The developer can then use normal Git tools (raw command-line or otherwise) as desired. When it is time to upload changes, dgit sbuild constructs the source package. Then, a dgit push both pushes the current HEAD to the remote Git repository on Alioth and uploads the source package to the Debian archive.

Where things get more difficult are those situations when a package is modified outside of changes made directly on the dgit local branch, such as with a set of patches. The tool includes a dgit quilt-fixup command to integrate with the quilt patch manager (which lets maintainers keep track of a set of patches that need to be applied before each upload). The quilt-fixup command creates a "synthetic commit" which is then added to the Git history before the package is pushed. However, as Jackson noted in the man page and on the debian-devel mailing list, this is an imperfect solution.

Jackson pointed out some peculiarities of quilt that make it incompatible (at least for the time being) with dgit. For example, when one uses dpkg-source to build a source package in Debian's quilt-compatible format, if the result is then extracted (again using dpkg-source), the contents are not identical to the original—specifically, there are extra metadata files generated. This makes it difficult to use quilt to apply a set of patches and push the results with dgit, so Jackson recommended steering clear of quilt-formatted source packages altogether.

On the mailing list, Raphael Hertzog took some umbrage at Jackson's description of this issue as "brain damage" on quilt's part. In the ensuing discussion, Hertzog and Jackson eventually reached an impasse. The disagreement boils down to what is considered the "normal" workflow—specifically, how a developer should manage both local changes and a set of quilt-managed patches. Hertzog contends that developers should record their own local changes as a separate patch in quilt, while Jackson believes local changes should be orthogonal to those patches managed in quilt. But when using Jackson's workflow, quilt copes with the local changes by adding additional metadata, in the form of those the extra files seen by dkpg-source.

In any case, Jackson eventually decided to simply work around the oddities that result from trying to use quilt and dgit together. It is certainly possible for a developer to use dgit without worrying about the issue, merely by not bringing quilt into the mix. Of course, asking a developer to start using a different workflow is rarely a welcome suggestion, but there is hope that the distinctions will eventually be smoothed over.

There are some other limitations, however. For now, dgit is only usable by official Debian Developers (DDs); non-DDs cannot even create a read-only view of a dgit repository. This is due to the access control setup deployed on the Debian servers; it may be resolved in the future when Jackson and the system administrators have sufficient time.

Hertzog also inquired whether there might be any lessons to learn from Ubuntu's Distributed Development (UDD) project, which automatically imported all packages in the Ubuntu and Debian archives into repositories for use with Bazaar. "Automatic" import is in many ways wishful thinking; as several reported, Ubuntu found that there are a variety of special cases that dictate manual intervention to repair an imported package, and it can be problematic to get the full commit history of each package—which can involve upstream changes, patches, and commits made by individual developers. Ubuntu had it easier than Debian because UDD was limited to a single, Bazaar-based workflow. Since Debian is (at least for the foreseeable future) committed to giving its developers and maintainers the freedom to use any workflow they wish, deploying something like dgit for the entire Debian package archive would probably require more people-power than the project has.

No doubt many interesting things could be done with the availability of a Git repository containing the entire Debian archive, and accessible to the world. Dgit is not likely to reach that stage any time soon, but, as Jackson pointed out, he wanted something that he could deploy and use immediately. And it is clearly good news that Debian developers can begin using dgit now; Git has proven itself to be the version-control system of choice in free software at large, so integrating it with one of the premiere free software distributions is sure to reap benefits for developers and Debian users alike.

Comments (4 posted)

Brief items

Distribution quote of the week

Comments (none posted)

LFS-7.4 is released

Full Story (comments: none)

Distribution News

Debian GNU/Linux

bits from the DPL - August 2013

Full Story (comments: none)

BSP in Munich

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• This Week in CyanogenMod (September 6)
• DistroWatch Weekly, Issue 524 (September 9)
• MWKN (September 9)
• Tails report (August)
• Ubuntu Weekly Newsletter, Issue 333 (September 8)

Comments (none posted)

Wireless Aside, Cr OS Linux Delivers the Best of Two Worlds (LinuxInsider)

Comments (4 posted)

Page editor: Rebecca Sobol

Development

Birdfont

For many years, FontForge has been the only option for editing or designing fonts with free software. But FontForge can be an intimidating tool with a difficult learning curve, and over the years it had begun to get long in the tooth, with little regular attention from active developers. The development situation has improved significantly of late, but those who need a quick and easy-to-learn open source font editor now have another option in Birdfont.

It's a draw

Birdfont is the work of Johan Mattsson, who announced the project in December 2012 on the CREATE mailing list, and has subsequently made a steady series of small releases. The latest is version 0.28, from August 2013. Birdfont is written in Vala, which is a language often closely associated with GNOME, but in addition to running on Linux, builds are provided for Mac OS X, Windows, and OpenBSD. Birdfont's feature set is limited in scope (at least when compared to FontForge or proprietary editors); it initially supported creating only TrueType fonts, although support for Embedded OpenType (EOT) and SVG fonts has since followed. Similarly, the initial emphasis was placed on providing a good drawing canvas, while support for features like kerning has developed slowly.

Nevertheless, the emphasis on a good canvas for editing glyphs does pay off: Birdfont's glyph editor is considerably easier to get started with than FontForge's—particularly for people who come from Inkscape, Illustrator, or other non-font-specific editing tools. The drawing area and the tools look modern, are rendered smoothly, and behave more like the components of a standard drawing application.

To give a few examples, Birdfont's coordinate grid is set of light-colored background lines, vector curves are always rendered as black-on-white lines, and those curves have easily-distinguished control points which one can grab with the mouse. In contrast, FontForge does not show a coordinate grid at all (just numeric coordinates in the toolbar), background guide lines and vectors are the same color, and control points are rendered in several different shapes and colors depending on what variety of curve and point they correspond to. The upshot is that it is easy to pick up Birdfont and just start "sketching" ideas. FontForge is pickier about how its drawing tools operate, which lends itself to a different workflow.

Of course, there are reasons—even, one would have to agree, good reasons—for many of the choices FontForge makes in these areas. But they do make the application harder to use for newcomers. Birdfont may yet have to implement user interface changes if it continues to add features, though, at which point maintaining simplicity will become a greater challenge. For example, it currently supports only one drawing layer, which looks very uncluttered. With multiple layers, the UI must distinguish which layer is active, such as by adding a layers panel or rendering inactive layers in a different color—either way, adding more clutter to the interface.

But there are also plenty of niceties than even the most die-hard FontForge fan would appreciate. For instance, font formats disagree about whether the outermost contour of a glyph should be oriented clockwise or counterclockwise (TrueType says clockwise, PostScript and OpenType CFF say counterclockwise). Of course, a glyph's contour is a closed curve, but the orientation tells the renderer in which order the points on that curve will be listed, which is helpful for less powerful renderers. FontForge makes the orientation of every contour an explicit property, and if it is incorrect with respect to the standard of the font exported, then the glyph is rendered wrong; Birdfont does not make contour orientation a property at all, and simply fills in the shape regardless of how it was drawn.

On the other hand, there are a number of usability quirks in Birdfont's editor that may be difficult to get used to. There are multiple unlabeled tool buttons with ambiguous icons (so that one must hover the mouse over them to see the help text appear). The contrast on the toolbar buttons is low, which can make it hard to tell which one is selected. Some of the buttons also revert to their previous state after one usage, while others persist. This can be tricky to keep track of mentally, especially when the low contrast makes them harder to see.

In addition, some of the tools do not behave in entirely obvious ways. For instance, when the "pencil" tool is selected, one can left-click to move or manipulate existing points on a drawing—but must right-click to add new points on a new curve, or double-left-click to add new points to an existing curve. Moving existing points seems more like it should be the job of the "move" tool, but the "move" tool is used to move, rotate, or resize whole paths. Separating the point tools from the path tools is a good way to prevent editing accidents like deleting a shape when you meant to delete a single point; Inkscape does the same thing, while FontForge does not offer such protection. In addition, the Birdfont "move" tool's on-canvas rotate-and-resize functionality is about as nice as they come, but, nevertheless, this behavior can be quite difficult to discover in the current interface.

At this point, there are also several unimplemented features that are shown in the UI, but cannot be used, such as the "circle" and "rectangle" tools. There are also a few peculiar controls that look like tool buttons but are not. They are in fact numeric sliders that control the grid spacing, stroke width, and background image scaling. To change any of the settings, one clicks the "button," holds it down, and moves the mouse cursor up or down. Being able to change these settings with the mouse is nice, but the tool button widget is being overloaded to do so.

Several of these quirks could be smoothed over with different widgets or tool icons, but documentation would go much further. One can only hope that it is on its way; there are a lot of details that need description (such as how and what the "Export" function actually generates), and getting up to speed with the drawing tools would be much easier with examples. Mattsson has created a few tutorial videos, which are a start, but leave a lot of uncovered ground where the newer features are concerned.

Details

Drawing characters is arguably the "fun part" of font editing, but eventually one must tackle the less glamorous tasks of letterspacing, kerning, hinting, and adding OpenType features (such as ligatures). Basic letterspacing can be done on-canvas: two vertical guides (one for the left "bearing" and one for the right) are available in the glyph view; one simply grabs them and drags them left or right to change the amount of space on either side. This is quite painless, but it is unfortunate that the exact coordinate values are not shown anywhere in the interface, and setting the left and right bearings to specific values is not supported.

Birdfont has only recently gained support for working on kerning, and the situation is similar to that of letterspacing. One can open up a kerning tab from the menu at the top, type in a few characters, then move a slider back and forth to set a kerning adjustment between any pair of adjacent letters. There is a school of thought which says that the exact numeric values for things like letterspacing and kerning are not important—after all, the sole point is to make adjustments until the result looks good to the decidedly un-scientific human eye. But in practice, not showing such values in the interface can make working on the font more difficult.

Of course, the "correct" way to do spacing adjustments is to generate a .TTF or .OTF font and put together test pages for print or for the web. On that task, too, the current version Birdfont does not disclose many details or options. Perhaps FontForge exposes too many export options (especially if one includes its detailed format-validation settings), but Birdfont is missing some key ones like selecting the glyph names and whole-font settings. Choosing "Export" from the file menu lets the user select an output directory, but not to specify what sort of output is created. As of 0.28, the export includes a .TTF font, an .EOT font, an .SVG font, and an HTML sample file; all four are generated with each export. However, I found the export to be buggy, generating empty .TTFs several times for reasons I have not yet been able to pin down.

Birdfont will save font projects in its own .bf file format, which is XML-based. I was not able to find a description of the format, but it looks more like SVG than it does the XML-based Unified Font Object (UFO) format. In an email, Mattsson said he plans to eventually move the application over to UFO, so that he does not have to maintain a file format in addition to an application.

In another format-related wrinkle, so far, creating kerning pairs from scratch is the only supported method; Birdfont will not recognize kerning tables that already exist in the file. There is a short roadmap on the project's wiki that indicates supporting is coming for some more font features, including reading existing kerning tables and ligature support.

Last word

The complaints about missing functionality and interface quirks should not be taken as criticism of the project. This is code which is still in development; it is quite natural for there to be many tasks as yet uncompleted. However, if anyone who finds FontForge daunting is interested in running Birdfont as an editor, it would be wise to take some precautions with respect to some of the missing features.

First, the undo command only undoes certain operations and is not accompanied by a redo command. Second, there is a "Preview" command available in the File menu; it seems to generate and overwrite a .TTF in the last-used directory, even though the .TTF is used only to show how the font looks in a preview window. Thus, if you have recently exported your work as a .TTF, Preview will overwrite it. Finally, while the drawing tools do not offer point-precise movements or transformations, you can at least have Birdfont display the exact grid coordinates of the mouse cursor by launching the application with birdfont --show-coordinates.

Birdfont has made remarkable strides in its short life thus far. In comparison, it is true that FontForge supports almost every font format and option under the sun (including, for example bitmapped fonts and Adobe's Multiple Master format), but for many everyday uses that is clearly overkill. For a lot of casual users, the most that they will ever want to edit a font is to open up an existing .TTF file and make a handful of small tweaks: changing an awkward character, adding a currency symbol, adding a slash to the zero, etc. For those users, Birdfont is excellent news indeed. It is easy to get started with, the drawing tools look modern and nice, and there is very little chance that they will generate output with the wrong settings.

Perhaps Birdfont will add enough features to compete with FontForge for high-end users, too, but in the meantime it is refreshing to see another take on the free software font editor, and it is nice to have an option that targets simplicity and ease of use.

Comments (none posted)

Brief items

Quote of the week

Comments (none posted)

PostgreSQL 9.3.0 released

Full Story (comments: none)

digiKam 3.4.0 available

Version 3.4.0 of the digiKam photo-management application has been released. No new user-visible functionality is incorporated in this version, however, 3.4.0 does mark the debut of a rewritten image-management core that takes full advantages of multiple CPUs and multiple cores. Thus allowing everyone to process their vacation photos far more rapidly, among other uses.

Full Story (comments: none)

LibreJS 5.3 released

Version 5.3 of the LibreJS tool has been released. LibreJS is an extension for Mozilla-based browsers, and is designed to block non-trivial JavaScript that is not demonstrably free software. 5.3 is actually an update that corrects compatibility problems in the just-released 5.2. New features in 5.2 and 5.3 include per-script controls for blocking and allowing content, improved matching of HTTPS URLs, and support for "magnet" links in addition to canonical URLs.

Full Story (comments: none)

Slony 2.2.0 released

Version 2.2.0 of the Slony master-to-multiple-slave replication engine for PostgreSQL has been released. Two major new features are included. Slony now uses the COPY command for replication, which "will result in faster replication times and more efficient resource utilization on the replica for many workloads," and the FAILOVER command "has been made more reliable for complex cluster configurations. The FAILOVER command now supports the failure of multiple nodes at the same time. All users of the FAILOVER should read the documentation to familiarize themselves with these changes."

Full Story (comments: none)

Newsletters and articles

Development newsletters from the past week

• Caml Weekly News (September 10)
• CloudStack Weekly News (September 4)
• What's cooking in git.git (September 9)
• OpenStack Community Weekly Newsletter (September 6)
• Perl Weekly (September 9)
• PostgreSQL Weekly News (September 8)
• Tor Weekly News (September 10)

Comments (none posted)

Patchfield introduces concepts of JACK audio server to Android (Libre Graphics World)

Libre Graphics World takes a look at the just-announced Patchfield audio server for Android. "In a nutshell, Patchfield reuses the cornerstone idea of JACK — creating standalone applications for audio generation and/or processing and connecting them in a patchbay." The fact that Patchfield brings advanced audio-processing capabilities to Android sounds like a plus in many ways, but there are evidently detractors who do not regard JACK's design as something to be closely emulated.

Comments (8 posted)

Page editor: Nathan Willis

Announcements

Brief items

Free Software Foundation statement on new iPhone models from Apple

Full Story (comments: none)

Defective By Design DRM FAQ

Full Story (comments: none)

Articles of interest

Lessons From Linux: How to Foster Collaboration at Meetings and Conferences (BizBash)

Comments (none posted)

Calls for Presentations

PyCon.DE 2013 calls to Open Source Projects

Full Story (comments: none)

CFP Deadlines: September 12, 2013 to November 11, 2013

If the CFP deadline for your event does not appear here, please tell us about it.

Upcoming Events

LibreOffice Conference 2013

Full Story (comments: none)

Celebrate GNU's big "three-o"

Full Story (comments: none)

lca2014 Speakers List

Full Story (comments: none)

Events: September 12, 2013 to November 11, 2013

If your event does not appear here, please tell us about it.

Page editor: Rebecca Sobol