Red Hat, Fedora, and containers

DevConf.cz is an annual conference in Brno, the second-largest city of the Czech Republic. While the conference is open to the public, both as attendees and as speakers, the majority of the 1600 people at the conference were Red Hat staff. As a first-time attendee and newly minted Red Hat employee, it felt like DevConf was a Red Hat internal technical conference that the public was invited to.

Fortunately, the company supports and contributes to enough different open-source projects to make for an interesting and varied program. Topics covered included Fedora, Project Atomic, OpenShift, CentOS, OpenStack, JBoss, and many smaller projects. And, thanks to the Red Hat engineering center in Brno, presentations tended to be technically detailed.

If there was a theme to this year's conference, though, it was Linux containers. Session after session either discussed technology and techniques for containers, or demonstrated other tools in conjunction with container infrastructures. This included sessions on immutable infrastructure, containerizing distributions, and the future of Fedora.

Red Hat containers with Project Atomic

Pretty much every company in the world of software today has a container story and even container products; Red Hat is no exception. Most of Red Hat's container efforts are funneled through Project Atomic, which is an umbrella project for multiple open-source tools and platforms. Among these are Atomic Host, the Atomic Developer Bundle, RPM-OSTree, as well as Atomic.app and the Nulecule specification. Red Hat staff also contribute to Docker, Kubernetes, and other third-party container tools, and the company is a member of the Open Container Initiative.

Atomic Host is probably the most visible of these efforts. Not really a project in itself, Atomic Host is a re-distribution, or "spin", of each of the three Red Hat platforms: Fedora, CentOS, and Red Hat Enterprise Linux (RHEL). Atomic Host is meant as a "thin OS" that only has the tools required to be a container-management platform, with the idea that all applications are installed as containers instead of packages. Its own software is managed through RPM-OSTree (see below), and it includes distributions of popular container tools such as Kubernetes, Docker, Flannel, and etcd. Atomic Host can be considered an alternative to CoreOS's Tectonic.

The Atomic Developer Bundle (ADB) is a virtual machine full of tools for building application container images. Packaged as a Vagrant virtual machine, it's intended to make it easy for developers on Windows and Mac laptops to get into container-based development. The ADB is less important on the Linux desktop, where all of these tools are available natively. The project serves the same purpose as the Docker Toolbox.

Another problem Red Hat engineers wanted to solve was to provide the ability to bundle important metadata and even multi-container applications without attaching them to a specific orchestration system. The Nulecule specification, and its sole implementation, Atomic.app, is meant as an answer to this. Packaging containers with structured metadata allows the Atomic.app software to generate code for any of several orchestration systems, such as Kubernetes or Mesos.

While many of the products based on these projects are still under heavy development, Red Hat has released an all-new version of their Platform-as-a-Service cloud, OpenShift, which is built on top of Project Atomic components. The new containerized infrastructure was praised at the conference as being more scalable, manageable, and faster than the previous design. OpenShift is available as an open-source stack in the OpenShift Origin project.

While it was already apparent that Red Hat was involved in Linux containers, DevConf.cz made it clear how central containers are to its plans for the OS in the future. Various presentations explained how the staff and executives plan to make use of container technologies and ideas to change how Linux is distributed and deployed. One of these ideas is "immutable infrastructure."

Immutable infrastructure and OSTree

Two presenters, Adam Miller of Fedora Engineering and Colin Walters of Platform Engineering, each explained in their presentations how the move to containerization, coupled with other new ideas, will change things.

In "The Magical Future", Adam Miller explained the idea of "immutable infrastructure". This has two principles, he said: full automation and the immutability of each component, which doesn't change from development through testing to deployment. The idea is that everything you deploy should be a "build artifact" that doesn't get configured at runtime. Instead, all configuration management happens at build time, the only exception being differences between development and production environments. Even those should be handled by read-only configurations; one per environment.

"The idea is that you don't configure services in the environment, you configure and re-deploy," explained Miller.

This principle of immutability is familiar in the Linux container world. Miller introduced the idea of an "immutable OS", based on RPM-OSTree on top of Atomic Host. OSTree, introduced in 2011, manages a root filesystem in a way that is similar to Git commits, where all files in a commit change at once. RPM-OSTree, created in 2014, takes this concept and applies it to RPMs and sets of RPMs. This makes updates to the Linux server "atomic" in nature, meaning they update or roll back as a unit.

The Atomic Host versions of Fedora and CentOS work on this principle of immutability by using RPM-OSTree. Instead of updating individual packages on each host, each server is copied from a "parent" image in the same way that Docker containers are copied from a filesystem image. No local changes to installed software are possible, only updates to synchronize with changes in the parent image.

Walters expanded on this in his session about "Containerizing the Distribution." Walters was recently involved in building OpenShift version 3, which required a total overhaul of the platform to use containerization and immutability. According to him, while containers have given us "new boxes", they haven't really changed how we build software.

Walters then demonstrated building a container using RPM-OSTree instead of "docker pull". Each "branch" of the OSTree represents a package, and can be treated like a "layer" of a container image. He said that this approach is superior because it makes it much easier to maintain common library packages across a container infrastructure. Right now, this approach is working only using a hacked version of the Mock build-and-chroot tool.

Walters also did a demonstration of container image creation starting from RPMs. Again using OSTree tools, he showed creating a Docker image directly from RPMs and then pushing it to a shared registry. Ideally, he explained, the registry would be on shared storage so container images could simply be mounted by the individual servers.

Containerization and the future of Fedora

While the presentation by Denise Dumas, VP of Platform Engineering at Red Hat, and Mathew Miller, Fedora Project Leader, wasn't marked as a keynote on the program, it might as well have been. Dumas's half of the talk was full of grand ideas and ended with a call to action. In it, she presented her vision of a new direction for the Fedora project, which unsurprisingly involves containers.

Part of the Fedora project values are the "four Fs": Freedom, Friends, Features, and First. To that, Dumas would like to add one more: "Faster". Increasingly, she explained, users are looking to rapid delivery of applications from their platform. She wants Fedora to help Red Hat find ways to deliver an OS that is faster, smaller, and more modular, while still being more secure.

"Two releases a year used to be fast," she said. "We want to be moving continuously, we want to be DevOps." From her perspective, Red Hat does a lot to support Fedora. In return, she wants Fedora to be the place where it can experiment with what it means to be an OS in 2016, or in 2020. Dumas claimed that "disruption is coming," and that Fedora should be part of it instead of being disrupted by it.

A lot of her vision for Fedora centers around containerization and immutability. This includes both Fedora Atomic Host and the new Fedora Atomic Workstation. The latter uses OSTree and xdg-app, a tool for sandboxing GUI applications, to deploy images and updates to developer workstations. Specific applications could be installed as containers, as they are on Atomic Host. Right now Atomic Workstation is still in early alpha stages, with plans for a prototype of Fedora 24.

Miller agreed with Dumas, saying "Fedora Atomic is the future of the operating system [...] Look at RancherOS. We need to be in the forefront of that." Most of his portion of the presentation reviewed the last year of Fedora's progress. Fedora had contributions from around 2000 people last year, of whom about 35% are Red Hat staff and the rest are from outside. Fedora Workstation, a variant of the distribution aimed at software developers, has been popular. So has the network install option for new machines.

He also showed the statistics from the various "spins" of Fedora, such as KDE, Security Lab, and Robotics. Fedora KDE has been popular since it was the first version of the OS to include Plasma 5. Other spins aren't used by as many people, but are the primary OS for their audiences. For example, Fedora Robotics has been the OS of choice for the DARPA-sponsored robot soccer matches.

The distribution is also replacing the venerable X server with the new Wayland graphics server. That will happen in either Fedora 24 or 25, depending on readiness.

Miller also mentioned the Fedora Layered Docker Image Build Service, which was explained in more detail in a later presentation by Fedora Release Engineer Dennis Gilmore. The new service will provide standard builds for images to be distributed as Fedora applications. In Fedora 24, the service will be simply available, but by Fedora 25 it is expected that some applications will be distributed as containers instead of as traditional packages. The project will also be creating its own container-image registry to support this.

More to come

Of course, not everything on the road to Red Hat containers has been a smooth ride. Dan Walsh detailed some of the technical conflicts with Docker, in his presentation "Systemd vs. Docker", which will be covered in a later article.

DevConf.cz was full of all sorts of other interesting projects thanks to presentations by what seemed like half of Red Hat's engineering staff. This also included the Cockpit server management GUI, the FreeIPA identity management server, a new configuration management tool, the CentOS build service, and more. Look for further coverage in the coming weeks.

Comments (3 posted)

Learning about community

Communities that form around open source and open hardware tend to have a strong DIY — Do It Yourself — focus. At its best, this can result in innovation and value creation on multiple fronts. At its worst, this risks getting caught up in NIH syndrome, where anything Not Invented Here seems unworthy of our time. Chris Cormack brought a message [WebM] to linux.conf.au to warn against letting NIH affect our approach to community building and to encourage us to look beyond ourselves to learn about community. He himself identified as a member of two very different communities and found that the wisdom of the more ancient culture was quite beneficial in building the nascent one.

In the first place he is a Māori — the people who have inhabited New Zealand for the last 700 years. He does not look like a typical Māori and admitted that he is probably one of the palest Māoris you will see. He described himself as a "stealth" Māori, though he can trace his lineage back 47 generations. Today the south island of New Zealand is known for its spectacular beauty but, when Cormack's forebears arrived centuries ago, they found a land that was "freezing cold, where nothing would grow, and that had no land mammals". Without the food, transport, and labor that such mammals might provide, building a strong, healthy community was important for survival.

The second community Cormack identified with was the development community for the Koha open-source library-management system. Koha was built by Cormack and some colleagues when a local library discovered, with only a few months to spare, that its current proprietary system had a Y2K problem that could not be fixed. Motivated by those immortal words "how hard can it be?", they started learning about libraries and building software — managing to go live on January 3, 2000.

The Koha community has grown over the years (though not so much in New Zealand or Australia as might have been hoped) with installations around the world, translations to "30ish" languages and a great deal of diversity. Cormack particularly noted that the combination of librarians (traditionally female) and developers (traditionally male) has resulted in an unusually good gender balance. He was also rather proud to have received security fixes from a Benedictine monk, accessibility fixes from a blind Buddhist monk, and was still hoping to hear from a Trappist monk as they apparently make good beer.

Cormack noted a few Māori proverbs that focused on community, several of which had close English equivalents such as "many hands make light work" or "we stand on the shoulders of giants", but structured his presentation around five Māori terms that are part of common discourse in that culture. They serve to sum up that community's wisdom and to remind us of some important values. While these terms might superficially seem familiar, some carry an emphasis that can challenge our thinking.

Mana tangata — from where comes your reputation?

"Mana", we were told, is a term you will often hear in New Zealand. It can be translated as "respect" or "prestige", but it is more; it is much richer than these terms. A possible cognate that came up in other talks during the week is "reputation" — how we are known to and are perceived by others.

In her keynote [WebM] on Friday, where she discussed some of her research as an anthropologist looking at people interacting with technology, Genevieve Bell observed that people have a wide range of responses to issues of privacy: some are very protective, some give their data away without a second thought. However, when the conversation is turned around to be about reputation, responses are much more focused. People care about their reputation, realize that it can be based on even the tiny things they do, and are concerned about ubiquitous surveillance affecting their reputation even if they don't care about privacy.

"Mana tangata" presents a sharp contrast to this perspective of reputation based on what we have done. Rather, it refers to respect/prestige/strength/value/reputation that comes not from what you have done, but from the community you are a part of. Cormack offered a quote that he particularly liked from author Michael P. Shirres, who explained the concept this way: "To be a person is not to stand alone, but to be one with one's people and the deeper the oneness the more we are truly persons and have that mana tangata."

This view of reputation or prestige coming from community does not conflict with the view of it coming from actions, but is really just an alternate perspective that can lead to a different way of thinking. Cormack demonstrated this by linking mana tangata with the importance of welcoming people into a community. By doing this, by connecting people with ourselves, we build up their mana as well as strengthen our community.

This idea of the importance of giving, not just of gaining, reputation is central to the thoughts Katie McLaughlin had to share in her five minutes of "lightning talk" in the final session of the conference. In part, McLaughlin was championing the "#LABHR" initiative: Let's All Build a Hat Rack. To "hang your hat on" something is an idiom for basing your reputation on that something. Building on that analogy, a hat rack could be a collection of skills, experiences, contributions, etc. that together form a person's reputation. We can all participate in building hat racks by publicizing and celebrating the contributions of others, particularly the otherwise unseen contributions.

This is a slightly different emphasis than the one presented by Cormack. In mana tangata, the community doesn't provide the reputation, it is the reputation. However, it is a practical way of seeing reputation as something that a community gives, rather than something an individual must gain.

Whakanuia — effective teaching

"Whakanuia" is pronounced with an "F" sound for the "Wh". Cormack summarized it as an approach to teaching focused on "reward the good, ignore the bad". He gave examples of a couple of gifts he had received from grateful members of the Koha community. These were of minimal monetary value (e.g. a jar of peanut butter), but of significant community-building and motivational value. Little rewards can have a big effect.

In the other direction, Cormack described his "unsung heroes" announcements. Many projects announce lists of new features and fixed bugs. For Koha there are regular lists of contributors and contributions. This is more than just a list of authors from a Git log; it identifies a mix of contributions both tangible and intangible, both named and anonymous, as every contributor deserves to be celebrated.

Cormack did not expand on the importance of ignoring the bad, and maybe that is for the best. Maybe it is beneficial to just save our energies for celebrating the good that we see.

Kaiakopono — mentorship

This is probably the least challenging of the ideas that were presented. "Kaiakopono" means much the same as "mentoring", though perhaps with an extra spoonful of "welcoming" thrown in. Cormack borrowed an interpretation from author Esther Schindler, who wrote: "Not everyone needs to be the welcome wagon — but someone ought to be."

The importance of mentoring seems to be well understood in open-source communities; there are a range of programs that encourage and support it. There is little to take away from this Māori term except maybe to be reminded of what we already know is important. It is also rewarding: Cormack rejoiced in the "massive buzz" he gets when someone he'd been helping doesn't need help any more.

Korerorero and whakaaro whānui — conflict and resolution

Conflict and disagreement are inevitable in any community. How a community handles those inevitabilities can shape how the community is perceived — it certainly appears that many see the Linux kernel community in terms of the conflicts on its mailing list.

Korerorero, according to Cormack, is somewhere between "argue" and "discuss". It is about coming together to address issues and to present opinions and to gain understanding. It is also about eating and drinking together. It seems that something different happens when discussions, particularly passionate discussions, are held around a meal table. Maybe it is the reminder of community, or perhaps the food distracts those with less firm opinions. Cormack highlighted the success of the "KohaCon" conferences that meet in a different country each year; he noted that all of his photos from the conferences seemed to have wine bottles on the tables.

Face-to-face meetings are clearly not always possible in a global community, so when they do take place, it is important to understand how to make the most of them. Learning from a different community that handles meetings effectively certainly seems like good advice. This makes one wonder how the Kernel Summit would go if the meetings were over a meal instead of between meals.

The outcome of korerorero will hopefully be "whakaaro whānui". This is people in agreement. It may not be complete unanimity, but Cormack characterized the outcome as one in which no one may be blamed if the result doesn't work out, but where everyone shares the credit when it does. This seems very close to the "rough consensus" that has been a big part of enabling the IETF (Internet Engineering Task Force) community.

This was highlighted by George Fong in his keynote address [WebM] on Tuesday, when he reminded us of some of the details of how the Internet was built; he noted the IETF, which has been quite successful over many decades and "simply works" despite the fact that: "There isn't a single law in place that governs them, there isn't a single overarching governance process which is imposed on them."

To explain the reason for that success, he quoted David Clark who is recorded in "The Tao of IETF" as saying: "We reject kings, presidents and voting. We believe in rough consensus and running code."

Fong's thoughts on the IETF can be used to assess other communities. Running code is something that is highly valued throughout the open-source world. Whether rough consensus is so highly valued is less clear. It is certainly not hard to identify projects, both past and present, that demonstrated a degree of success with real working code, but for which there was no community consensus — rough or otherwise. Some of these have brought about both real technological value and significant community division. Whether the one was worth the other is an interesting question. It probably depends on which one values more: the technology or the community.

He aha te mea nui?

That question leads quite nicely to the title of Cormack's talk, "He aha te mea nui?", which roughly translates as "What is the most important thing?". The traditional answer is "he tangata, he tangata, he tangata": the people, the people, the people. It is clear that for Cormack and the Koha community, it is the people and the community that are most important. The technology certainly has importance, but its true importance derives from how it provides access to knowledge, allows people to contribute, and encourages everyone to be involved.

Whether the community exists to serve the technology or the technology exists to serve the community, it is clear that a healthy community is important. But it is also often clear that technologists aren't experts in that area. Cormack's final encouragement was to learn from communities by joining them. There are plenty of communities around us that have been learning from their mistakes for much longer than the Internet or free software has been around. We might learn something by observing, by volunteering, or by joining. Many of the challenges we face are not new at all.

Comments (1 posted)

Winning the copyleft fight

Bradley Kuhn started off his linux.conf.au 2016 talk by stating a goal that, he hoped, he shared with the audience: a world where more (or most) software is free software. The community has one key strategy toward that goal: copyleft licensing. He was there to talk about whether that strategy is working, and what can be done to make it more effective; the picture he painted was not entirely rosy, but there is hope if software developers are willing to make some changes.

Copyleft licensing is still an effective strategy, he said; that can be seen because we've had the chance to run a real-world parallel experiment — an opportunity that doesn't come often. A lot of non-copyleft software has been written over the years; if proprietary forks of that software don't exist, then it seems clear that there is no need for copyleft; we just have to look to see whether proprietary versions of non-copyleft software exist. But, he said, he has yet to find a non-trivial non-copyleft program that lacks proprietary forks; without copyleft, companies will indeed take free software and make it proprietary.

As an example, he noted that the version of OpenStack running behind his Rackspace account clearly has features that are not in the free version. He does not know of a single OpenStack product that does not contain at least a few features that have not been pushed back upstream.

There is more and more non-copyleft software out there, he said, but copyleft itself remains the most viable strategy to bring about software freedom. Other strategies can be employed, but we need to continue with copyleft as the centerpiece. Unfortunately, it is not working as well as we would like for one simple reason: there is less copyleft software being produced.

Corporate opposition to copyleft

There is not much support for copyleft in the corporate world; Martin Fink's recent LinuxCon Europe talk was the first positive words he's heard from a company about copyleft in quite a while. In general, though, companies are embracing free software; even Apple is, to an extent. They have discovered that they cannot beat the free-software community, so they have now switched to an approach of coopting that community. The result is the emergence of groups claiming to speak for the community, saying that copyleft is no longer wanted. He has heard developers say that users prefer permissive licenses and that it's impossible to get funding for work on copyleft-licensed software. Why are they saying that? In the end, Bradley said, if you hear things enough times you may well start to believe them.

As one might imagine, he sees the lack of enforcement for the code that is under copyleft licensing as a big problem. The only people who can change that, he said, are developers who hold their own copyrights in the code. Companies, which hold most copyrights at this point, will never do enforcement. Or, on the rare occasion when they do, it is to support their own goals rather than to defend the freedom of the software. One example is MySQL, which was happy to use the GPL as a way to force companies to buy proprietary licenses. Red Hat alleged GPL infringement against Twin Peaks Software as a way of defending itself against a patent troll; in the end, Red Hat got its patent license, and Twin Peaks Software's code remains proprietary.

The Software Freedom Conservancy recently published a set of principles that, they say, should govern GPL enforcement; the first of those is that the primary objective is to bring about license compliance. Since then, no trade association or company has endorsed those principles.

That is the case, he said, because lawyers in the corporate world have gained control over policy with regard to the GPL, and they are actively coordinating to try to push the GPL aside. They hold "secret meetings" in which to work through scenarios of possible enforcement actions and how to prevail against them. There have been "two meetings" with the purpose of finding ways to increase corporate ownership of GPL-licensed software as a way of curtailing enforcement by individuals.

The result, he said, is a crisis for the concept of copyleft. If copyleft is the right strategy, then some way has to be found to deal with these challenges. We need a plan.

Defending copyleft

The copyleft strategy works best when copyrights are held by people and institutions that hold software-freedom principles. That means individuals and charities, he said; companies and trade associations do not subscribe to those principles. Thus, he said, developers who support software freedom should go to their employers and insist on being allowed to hold their own copyrights. Perhaps developers should unionize to demand this right. Then they should join one of the Conservancy's coalitions for enforcement.

He also called for developers to go back to volunteer coding — off hours, it is not necessary to quit one's job to do this (though he did note that some companies will claim ownership of even an employee's off-hours work). Early free software was written this way. Bradley said that he works nights and weekends for the cause; he would like for the development community to do the same. Developers should also be willing to fork permissively licensed software under copyleft when necessary.

But copyleft won't work if we don't enforce the terms of the license, he said. Enforcement is getting harder: companies are actively working to replace copyleft-licensed software. Toybox and LLVM are two examples there. Given that, which essential copyleft-licensed software remains?

The one thing that companies haven't tried to rewrite, he said, is the Linux kernel. Thus Linux is the battleground over which the future of copyleft licensing will be determined. An area of immediate interest is proprietary modules, and whether they are derived works of the kernel; he has not yet seen one that didn't look that way to him. There are corporate lawyers who want to fight over this issue; it is a fight that the community will have to take on. If we shrink from this particular confrontation, we will no longer have effective copyleft licensing.

Once upon a time, he assumed that most license violations were innocent mistakes. Those days are coming to an end. Most violations, he alleged, are done deliberately by companies that hire lawyers in advance to plan strategies should it come to a fight. The community is helping these companies with its openness. This is, he said, a zero-sum game; the two sides have diametrically opposed goals.

GPL enforcement requires more than copyright holders, though; it also requires funding. That is a problem; enforcement as a profit-making enterprise is a path to corruption. Violators will always ask how much it will cost to buy permission, but if owners take money without demanding full compliance, they are just another player in the proprietary relicensing business. Companies will not support this work, so the only way is for the community to support it. He reminded the audience of the Conservancy's funding drive, which continues through February.

He concluded by saying that his plan can easily be described as simple-minded. It depends on a community of individuals coming together to stand up for software freedom and the GPL. But this should be possible: uniting and working toward a common goal is just what the community is good at doing.

The video for this talk is available on the LCA site.

[Your editor thanks LCA for assisting with his travel expenses.]

Comments (247 posted)

A side-channel attack on GnuPG

Using equipment that is reminiscent of the Van Eck phreaking scene in Cryptonomicon, some security researchers have shown that keys can be extracted from a laptop in the next room. It is a passive attack that exploits a side channel in the GNU Privacy Guard (GnuPG) implementation of the Elliptic Curve Diffie-Hellman (ECDH) key-exchange protocol. The problem has been fixed in Libgcrypt, but the possibility of similar weaknesses in other algorithms or implementations makes this kind of attack worthy of some study by those working in cryptography.

The paper [PDF] that describes the technique was authored by Daniel Genkin, Lev Pachmanov, Itamar Pipman, and Eran Tromer, who are researchers at Tel Aviv University. There are pictures of the equipment used in the paper, as well as on a web page with some FAQs on the technique. The current setup costs around $3000 for the equipment needed to intercept the electromagnetic (EM) signals from a computer on the other side of a wall, but it is believed that much less expensive (and more portable) equipment could be developed.

The basic idea is to measure the EM output of the laptop as it decrypts chosen ciphertext. GnuPG is used by tools like the Enigmail plugin for Mozilla Thunderbird, so email can be used as a way to cause the laptop to do the decryption. Enigmail will automatically pass encrypted email to GnuPG for decryption, which means that email sent will result in decryption that can be captured in the next room. Multiple emails were sent to improve the reliability of the key extraction. So, by sending emails encrypted with a victim's public key, an attacker (or government agency) in the next room can recover most of the victim's private key—thus decrypt any other encrypted email that has been intercepted.

In Libgcrypt 1.6.3 and earlier, the decryption algorithm does an optimization that allows the key to be recovered. Large integers (such as keys) are represented in non-adjacent form (NAF) in order to reduce the number of non-zero digits (each of which requires additional arithmetic operations) from roughly one-half to one-third. Numbers in that form are strings of 1, 0, and -1 values.

By observing the operations performed on the ciphertext, the researchers were easily able to distinguish the 0 "bits" in the key, but there was still a problem determining whether the non-zero values were 1 or -1. That's where choosing the ciphertext comes into play. By using specific points on the elliptic curve in the ciphertext, the researchers could reliably distinguish between the sequence of operations done for a 1 value versus those done for a -1 value.

The net result is described in the paper:

While the entire key is not necessarily extracted, the search space has been reduced enormously. Presumably, brute-force techniques can determine the missing digits and any errors in short order.

In order to avoid this side-channel leak, Libgcrypt 1.6.5 was released. It always does the same set of operations for each digit, regardless of its value. The researchers worked with the GnuPG developers to ensure that the change resisted the attack. The new algorithm is slower, but won't be subverted with this technique. Other tools use Libgcrypt, too, of course, so the update is important. The big unknown is whether other implementations of ECDH are vulnerable—and what other side channels (in other cryptographic algorithms) are out there waiting to be found.

Cryptographic algorithms are hard to get right even before considering problems like side channels. While these kinds of attacks are not particularly new, they do represent a threat to users, particularly from targeted, nation-state-level attackers. Though, as noted in the FAQ, this kind of attack is unlikely to be used except against the most security conscious:

For those who are taking more precautions than most, however, these techniques have to be a little worrisome. It is not terribly hard to imagine some agency setting up shop in the next hotel room over and monitoring the activity of the laptop next door, then sending these targeted emails and collecting the data needed. The best defense may well be to ensure that decryption only takes place under the direction of the user—and in a secure location.

Comments (12 posted)

Security quotes of the week

— Apple CEO Tim Cook

— Alan Cox on the Glibc DNS lookup remote code execution vulnerability

— Lauren Weinstein

Comments (27 posted)

A remote code execution vulnerability in glibc

The Google Online Security Blog discloses a security issue in the GNU C library; a fix, workarounds, and a proof-of-concept exploit are all provided. "The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack."

See also: the glibc advisory for this issue.

Comments (15 posted)

389-ds-base: denial of service

Package(s):	389-ds-base	CVE #(s):	CVE-2016-0741
Created:	February 16, 2016	Updated:	February 23, 2016
Description:	From the Red Hat advisory: An infinite-loop vulnerability was discovered in the 389 directory server, where the server failed to correctly handle unexpectedly closed client connections. A remote attacker able to connect to the server could use this flaw to make the directory server consume an excessive amount of CPU and stop accepting connections (denial of service).
Alerts:	Fedora FEDORA-2016-40401300ed 389-ds-base 2016-03-09 Fedora FEDORA-2016-0609474cf6 389-ds-base 2016-03-09 Mageia MGASA-2016-0081 389-ds-base 2016-02-23 Scientific Linux SLSA-2016:0204-1 389-ds-base 2016-02-16 Oracle ELSA-2016-0204 389-ds-base 2016-02-16 CentOS CESA-2016:0204 389-ds-base 2016-02-17 Red Hat RHSA-2016:0204-01 389-ds-base 2016-02-16

Comments (none posted)

asterisk: file descriptor exhaustion

Package(s):	asterisk	CVE #(s):	CVE-2016-2316
Created:	February 17, 2016	Updated:	March 3, 2016
Description:	From the Red Hat bugzilla: It was reported that setting the sip.conf timert1 value to a value higher than 1245 can cause an integer overflow and result in large retransmit timeout times. These large timeout values hold system file descriptors hostage and can cause the system to run out of file descriptors.
Alerts:	Debian DSA-3700-1 asterisk 2016-10-25 Mageia MGASA-2016-0086 asterisk 2016-03-02 Fedora FEDORA-2016-3cc13611f4 asterisk 2016-02-17 Fedora FEDORA-2016-153eed2bb8 asterisk 2016-02-17

Comments (none posted)

botan: three vulnerabilities

Package(s):	botan	CVE #(s):	CVE-2016-2194 CVE-2016-2195 CVE-2016-2196
Created:	February 11, 2016	Updated:	December 13, 2016
Description:	From the Arch Linux advisory: CVE-2016-2194 - (denial of service) - The ressol function implements the Tonelli-Shanks algorithm for finding square roots could be sent into a nearly infinite loop due to a misplaced conditional check. This could occur if a composite modulus is provided, as this algorithm is only defined for primes. This function is exposed to attacker controlled input via the OS2ECP function during ECC point decompression. CVE-2016-2195 - (arbitrary code execution) - The PointGFp constructor did not check that the affine coordinate arguments were less than the prime, but then in curve multiplication assumed that both arguments if multiplied would fit into an integer twice the size of the prime. The bigint_mul and bigint_sqr functions received the size of the output buffer, but only used it to dispatch to a faster algorithm in cases where there was sufficient output space to call an unrolled multiplication function. The result is a heap overflow accessible via ECC point decoding, which accepted untrusted inputs. This is likely exploitable for remote code execution. On systems which use the mlock pool allocator, it would allow an attacker to overwrite memory held in secure_vector objects. After this point the write will hit the guard page at the end of the mmap’ed region so it probably could not be used for code execution directly, but would allow overwriting adjacent key material. CVE-2016-2196 - (arbitrary code execution) - The P-521 reduction function would overwrite zero to one word following the allocated block. This could potentially result in remote code execution or a crash.
Alerts:	Debian-LTS DLA-449-1 botan1.10 2016-04-30 Debian DSA-3565-1 botan1.10 2016-05-02 Gentoo 201612-38 botan 2016-12-13 Mageia MGASA-2016-0102 botan 2016-03-07 Fedora FEDORA-2016-1c08d77b96 qt-creator 2016-02-29 Fedora FEDORA-2016-1c08d77b96 qca 2016-02-29 Fedora FEDORA-2016-1c08d77b96 monotone 2016-02-29 Fedora FEDORA-2016-1c08d77b96 code-editor 2016-02-29 Fedora FEDORA-2016-1c08d77b96 botan 2016-02-29 Fedora FEDORA-2016-fb9b356b74 qt-creator 2016-02-23 Fedora FEDORA-2016-fb9b356b74 qca 2016-02-23 Fedora FEDORA-2016-fb9b356b74 monotone 2016-02-23 Fedora FEDORA-2016-fb9b356b74 code-editor 2016-02-23 Fedora FEDORA-2016-fb9b356b74 botan 2016-02-23 Arch Linux ASA-201602-11 botan 2016-02-10

Comments (none posted)

cacti: authentication bypass

Package(s):	cacti	CVE #(s):	CVE-2016-2313
Created:	February 12, 2016	Updated:	February 18, 2016
Description:	From the openSUSE advisory: CVE-2016-2313: Authentication using web authentication as a user not in the cacti database allows complete access
Alerts:	Debian-LTS DLA-560-2 cacti 2016-09-01 Debian-LTS DLA-560-1 cacti 2016-07-26 Gentoo 201607-05 cacti 2016-07-16 Mageia MGASA-2016-0068 cacti 2016-02-17 openSUSE openSUSE-SU-2016:0440-1 cacti 2016-02-12 openSUSE openSUSE-SU-2016:0438-1 cacti 2016-02-12 openSUSE openSUSE-SU-2016:0437-1 cacti 2016-02-12

Comments (none posted)

chromium: multiple vulnerabilities

Package(s):	chromium-browser	CVE #(s):	CVE-2016-1622 CVE-2016-1623 CVE-2016-1624 CVE-2016-1625 CVE-2016-1626 CVE-2016-1627
Created:	February 17, 2016	Updated:	February 22, 2016
Description:	From the CVE entries: The Extensions subsystem in Google Chrome before 48.0.2564.109 does not prevent use of the Object.defineProperty method to override intended extension behavior, which allows remote attackers to bypass the Same Origin Policy via crafted JavaScript code. (CVE-2016-1622) The DOM implementation in Google Chrome before 48.0.2564.109 does not properly restrict frame-attach operations from occurring during or after frame-detach operations, which allows remote attackers to bypass the Same Origin Policy via a crafted web site, related to FrameLoader.cpp, HTMLFrameOwnerElement.h, LocalFrame.cpp, and WebLocalFrameImpl.cpp. (CVE-2016-1623) Integer underflow in the ProcessCommandsInternal function in dec/decode.c in Brotli, as used in Google Chrome before 48.0.2564.109, allows remote attackers to cause a denial of service (buffer overflow) or possibly have unspecified other impact via crafted data with brotli compression. (CVE-2016-1624) The Chrome Instant feature in Google Chrome before 48.0.2564.109 does not ensure that a New Tab Page (NTP) navigation target is on the most-visited or suggestions list, which allows remote attackers to bypass intended restrictions via unspecified vectors, related to instant_service.cc and search_tab_helper.cc. (CVE-2016-1625) The opj_pi_update_decode_poc function in pi.c in OpenJPEG, as used in PDFium in Google Chrome before 48.0.2564.109, miscalculates a certain layer index value, which allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted PDF document. (CVE-2016-1626) The Developer Tools (aka DevTools) subsystem in Google Chrome before 48.0.2564.109 does not validate URL schemes and ensure that the remoteBase parameter is associated with a chrome-devtools-frontend.appspot.com URL, which allows remote attackers to bypass intended access restrictions via a crafted URL, related to browser/devtools/devtools_ui_bindings.cc and WebKit/Source/devtools/front_end/Runtime.js. (CVE-2016-1627)
Alerts:	Mageia MGASA-2016-0127 chromium-browser-stable 2016-03-31 Gentoo 201603-09 chromium 2016-03-12 openSUSE openSUSE-SU-2016:0518-1 Chromium 2016-02-20 Debian DSA-3486-1 chromium-browser 2016-02-21 Ubuntu USN-2895-1 oxide-qt 2016-02-18 openSUSE openSUSE-SU-2016:0491-1 Chromium 2016-02-17 Red Hat RHSA-2016:0241-01 chromium-browser 2016-02-17

Comments (none posted)

cpio: out-of-bounds write

Package(s):	cpio	CVE #(s):	CVE-2016-2037
Created:	February 15, 2016	Updated:	February 6, 2017
Description:	From the Debian LTS advisory: An out-of-bounds write was discovered in the parsing of cpio files. For Debian 6 "Squeeze", this issue has been fixed in cpio version 2.11-4+deb6u2.
Alerts:	openSUSE openSUSE-SU-2017:0389-1 cpio 2017-02-04 Ubuntu USN-2906-1 cpio 2016-02-22 Debian DSA-3483-1 cpio 2016-02-19 Mageia MGASA-2016-0063 cpio 2016-02-17 Debian-LTS DLA-415-1 cpio 2016-02-15

Comments (none posted)

eglibc: code execution

Package(s):	eglibc glibc	CVE #(s):	CVE-2015-7547
Created:	February 16, 2016	Updated:	February 24, 2016
Description:	From the Debian advisory: The Google Security Team and Red Hat discovered that the eglibc host name resolver function, getaddrinfo, when processing AF_UNSPEC queries (for dual A/AAAA lookups), could mismanage its internal buffers, leading to a stack-based buffer overflow and arbitrary code execution. This vulnerability affects most applications which perform host name resolution using getaddrinfo, including system services.
Alerts:	SUSE SUSE-SU-2016:0786-1 sles12-docker-image 2016-03-16 SUSE SUSE-SU-2016:0778-1 sles11sp4-docker-image 2016-03-15 SUSE SUSE-SU-2016:0748-1 sles12sp1-docker-image 2016-03-14 Slackware SSA:2016-054-02 glibc 2016-02-23 Mageia MGASA-2016-0079 glibc 2016-02-19 openSUSE openSUSE-SU-2016:0512-1 glibc 2016-02-19 openSUSE openSUSE-SU-2016:0511-1 glibc 2016-02-19 openSUSE openSUSE-SU-2016:0510-1 glibc 2016-02-19 Arch Linux ASA-201602-15 lib32-glibc 2016-02-17 Ubuntu USN-2900-1 eglibc, glibc 2016-02-16 SUSE SUSE-SU-2016:0470-1 glibc 2016-02-16 SUSE SUSE-SU-2016:0472-1 glibc 2016-02-16 SUSE SUSE-SU-2016:0473-1 glibc 2016-02-16 SUSE SUSE-SU-2016:0471-1 glibc 2016-02-16 Scientific Linux SLSA-2016:0175-1 glibc 2016-02-16 Scientific Linux SLSA-2016:0176-1 glibc 2016-02-16 Oracle ELSA-2016-0175 glibc 2016-02-16 Oracle ELSA-2016-0176 glibc 2016-02-16 openSUSE openSUSE-SU-2016:0490-1 glibc 2016-02-17 Gentoo 201602-02 glibc 2016-02-17 Fedora FEDORA-2016-0480defc94 glibc 2016-02-17 Fedora FEDORA-2016-0f9e9a34ce glibc 2016-02-17 Debian-LTS DLA-416-1 eglibc 2016-02-16 CentOS CESA-2016:0175 glibc 2016-02-17 CentOS CESA-2016:0176 glibc 2016-02-17 Arch Linux ASA-201602-14 glibc 2016-02-17 Red Hat RHSA-2016:0175-01 glibc 2016-02-16 Red Hat RHSA-2016:0176-01 glibc 2016-02-16 Red Hat RHSA-2016:0225-01 glibc 2016-02-16 Debian DSA-3481-1 glibc 2016-02-16 Debian DSA-3480-1 eglibc 2016-02-16

Comments (none posted)

eog: code execution

Package(s):	eog gtk+	CVE #(s):	CVE-2013-7447
Created:	February 16, 2016	Updated:	September 26, 2016
Description:	From the Ubuntu advisory: It was discovered that Eye of GNOME incorrectly handled certain large images. If a user were tricked into opening a specially-crafted image, a remote attacker could use this issue to cause Eye of GNOME to crash, resulting in a denial of service, or possibly execute arbitrary code.
Alerts:	openSUSE openSUSE-SU-2016:2366-1 gtk2 2016-09-24 openSUSE openSUSE-SU-2016:2374-1 gtk2 2016-09-24 Fedora FEDORA-2016-330bfc0338 gnome-photos 2016-03-21 openSUSE openSUSE-SU-2016:0647-1 eog 2016-03-03 Mageia MGASA-2016-0073 pinpoint 2016-02-17 Mageia MGASA-2016-0071 thunar 2016-02-17 Mageia MGASA-2016-0069 gtk+2.0 2016-02-17 Mageia MGASA-2016-0076 gnome-photos 2016-02-17 Mageia MGASA-2016-0075 gambas3 2016-02-17 Mageia MGASA-2016-0070 eom 2016-02-17 Mageia MGASA-2016-0074 eog 2016-02-17 Debian-LTS DLA-419-1 gtk+2.0 2016-02-17 Ubuntu USN-2898-1 gtk+2.0, gtk+3.0 2016-02-15 Ubuntu USN-2898-2 eog 2016-02-15

Comments (none posted)

firebird: denial of service

Package(s):	firebird	CVE #(s):	CVE-2016-1569
Created:	February 11, 2016	Updated:	February 17, 2016
Description:	From the Firebird advisory: Typo in gbak's command line parameter causes Firebird process to crash, ie: gbak -c -v -se service_mgr -user_all_space d:\backup.gbk d:\bd.fdb
Alerts:	Fedora FEDORA-2016-bec6b9c395 firebird 2016-02-11

Comments (none posted)

firefox: denial of service

Package(s):	firefox	CVE #(s):
Created:	February 11, 2016	Updated:	February 17, 2016
Description:	From the Red Hat bugzilla entry: Firefox crashes when I tried to open webradio playlistfiles directly
Alerts:	Fedora FEDORA-2016-2b49647f65 firefox 2016-02-11

Comments (none posted)

firefox: same-origin restriction bypass

Package(s):	firefox	CVE #(s):	CVE-2016-1949
Created:	February 12, 2016	Updated:	February 24, 2016
Description:	From the Ubuntu advisory: Jason Pang discovered that service workers intercept responses to plugin network requests made through the browser. An attacker could potentially exploit this to bypass same origin restrictions using the Flash plugin. (CVE-2016-1949)
Alerts:	Gentoo 201605-06 nss 2016-05-31 openSUSE openSUSE-SU-2016:0553-1 firefox 2016-02-24 openSUSE openSUSE-SU-2016:0489-1 firefox 2016-02-17 Fedora FEDORA-2016-8794abe899 firefox 2016-02-17 Arch Linux ASA-201602-12 firefox 2016-02-13 Ubuntu USN-2893-1 firefox 2016-02-11

Comments (none posted)

glibc: denial of service

Package(s):	glibc	CVE #(s):	CVE-2015-5229
Created:	February 17, 2016	Updated:	February 23, 2016
Description:	From the Red Hat advisory: It was discovered that the calloc implementation in glibc could return memory areas which contain non-zero bytes. This could result in unexpected application behavior such as hangs or crashes.
Alerts:	Scientific Linux SLSA-2016:0176-1 glibc 2016-02-16 Oracle ELSA-2016-0176 glibc 2016-02-16 CentOS CESA-2016:0176 glibc 2016-02-17 Red Hat RHSA-2016:0176-01 glibc 2016-02-16

Comments (none posted)

graphite2: information disclosure

Package(s):	graphite2	CVE #(s):	CVE-2016-1526
Created:	February 17, 2016	Updated:	February 17, 2016
Description:	From the CVE entry: The TtfUtil:LocaLookup function in TtfUtil.cpp in Libgraphite in Graphite 2 1.2.4, as used in Mozilla Firefox before 43.0 and Firefox ESR 38.x before 38.6.1, incorrectly validates a size value, which allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and application crash) via a crafted Graphite smart font.
Alerts:	Gentoo 201701-63 graphite2 2017-01-24 Gentoo 201701-35 seamonkey 2017-01-13 Fedora FEDORA-2016-338a7e9925 graphite2 2016-05-10 Scientific Linux SLSA-2016:0594-1 graphite2 2016-04-06 Oracle ELSA-2016-0594 graphite2 2016-04-05 CentOS CESA-2016:0594 graphite2 2016-04-05 Red Hat RHSA-2016:0594-01 graphite2 2016-04-05 openSUSE openSUSE-SU-2016:0875-1 graphite2 2016-03-24 openSUSE openSUSE-SU-2016:0791-1 graphite2 2016-03-16 SUSE SUSE-SU-2016:0779-1 graphite2 2016-03-15 Fedora FEDORA-2016-4154a4d0ba graphite2 2016-02-21 Mageia MGASA-2016-0078 thunderbird 2016-02-17 Mageia MGASA-2016-0077 graphite2/firefox 2016-02-17 Ubuntu USN-2902-1 graphite2 2016-02-17

Comments (none posted)

gsi-openssh: privilege escalation

Package(s):	gsi-openssh	CVE #(s):	CVE-2016-1908
Created:	February 11, 2016	Updated:	February 17, 2016
Description:	From the Red Hat bugzilla entry: It was discovered that OpenSSH client did not correctly handle situations when untrusted X11 forwarding was requested and generation of the untrusted authentication cookie failed. The ssh client continued by generating fake authentication cookie and allowed remote X clients to connect the local X server. The decision if client connection was accepted was delegated to the X server which, depending on its configuration, could allow clients to open trusted X connection. This would lead to remote X clients having more privileged access to the local X server than intended. This problem can occur when X server does not include or enable X Security extension (for X.org X server, this extension is not compiled in by default since 2007) and when it has authentication methods besides MIT cookies enabled (e.g. localuser authentication allowing all X connections from a local user who owns the X session).
Alerts:	Scientific Linux SLSA-2016:0741-1 openssh 2016-06-08 openSUSE openSUSE-SU-2016:1455-1 openssh 2016-05-31 Red Hat RHSA-2016:0741-01 openssh 2016-05-10 Ubuntu USN-2966-1 openssh 2016-05-09 Scientific Linux SLSA-2016:0465-1 openssh 2016-03-21 Oracle ELSA-2016-0465 openssh 2016-03-21 CentOS CESA-2016:0465 openssh 2016-03-21 Red Hat RHSA-2016:0465-01 openssh 2016-03-21 Gentoo 201612-18 openssh 2016-12-07 Fedora FEDORA-2016-4509765b4b gsi-openssh 2016-02-10

Comments (none posted)

libgcrypt20: key leak

Package(s):	libgcrypt20	CVE #(s):	CVE-2015-7511
Created:	February 12, 2016	Updated:	August 8, 2016
Description:	From the Debian advisory: Daniel Genkin, Lev Pachmanov, Itamar Pipman and Eran Tromer discovered that the ECDH secret decryption keys in applications using the libgcrypt20 library could be leaked via a side-channel attack. See https://www.cs.tau.ac.IL/~tromer/ecdh/ for details.
Alerts:	Gentoo 201610-04 libgcrypt 2016-10-10 Fedora FEDORA-2016-ec4c27d766 libgcrypt 2016-08-05 Fedora FEDORA-2016-83cd045bcc libgcrypt 2016-07-22 openSUSE openSUSE-SU-2016:1227-1 libgcrypt 2016-05-04 openSUSE openSUSE-SU-2016:0575-1 libgcrypt 2016-02-25 Arch Linux ASA-201602-19 libgcrypt 2016-02-25 Slackware SSA:2016-054-03 libgcrypt 2016-02-23 Mageia MGASA-2016-0072 libgcrypt 2016-02-17 Ubuntu USN-2896-1 libgcrypt11, libgcrypt20 2016-02-15 Debian DSA-3478-1 libgcrypt11 2016-02-15 Debian DSA-3474-1 libgcrypt20 2016-02-12

Comments (none posted)

libreoffice: code execution

Package(s):	libreoffice	CVE #(s):	CVE-2016-0794 CVE-2016-0795
Created:	February 17, 2016	Updated:	December 15, 2016
Description:	From the Ubuntu advisory: It was discovered that LibreOffice incorrectly handled LWP document files. If a user were tricked into opening a specially crafted LWP document, a remote attacker could cause LibreOffice to crash, and possibly execute arbitrary code.
Alerts:	Red Hat RHSA-2016:2579-02 libreoffice 2016-11-03 openSUSE openSUSE-SU-2016:1805-1 LibreOffice 2016-07-15 openSUSE openSUSE-SU-2016:1415-1 libreoffice 2016-05-27 Mageia MGASA-2016-0194 libreoffice 2016-05-22 Scientific Linux SLSA-2016:2579-2 libreoffice 2016-12-14 Fedora FEDORA-2016-962c0d156d libreoffice 2016-02-28 Debian DSA-3482-1 libreoffice 2016-02-17 Ubuntu USN-2899-1 libreoffice 2016-02-16

Comments (none posted)

mozilla: denial of service

Package(s):	firefox	CVE #(s):
Created:	February 15, 2016	Updated:	February 17, 2016
Description:	From the Fedora advisory: New upstream (44.0.2) - Fixed plugin crashes (rhbz#1259525)
Alerts:	Fedora FEDORA-2016-8794abe899 firefox 2016-02-17 Fedora FEDORA-2016-1d8f67dc76 firefox 2016-02-15

Comments (none posted)

mozilla: denial of service

Package(s):	iceweasel firefox thunderbird	CVE #(s):	CVE-2016-1523
Created:	February 15, 2016	Updated:	March 8, 2016
Description:	From the CVE entry: The SillMap::readFace function in FeatureMap.cpp in Libgraphite in Graphite 2 1.2.4, as used in Mozilla Firefox before 43.0 and Firefox ESR 38.x before 38.6.1, mishandles a return value, which allows remote attackers to cause a denial of service (missing initialization, NULL pointer dereference, and application crash) via a crafted Graphite smart font.
Alerts:	Gentoo 201701-63 graphite2 2017-01-24 Gentoo 201701-35 seamonkey 2017-01-13 Gentoo 201605-06 nss 2016-05-31 Fedora FEDORA-2016-338a7e9925 graphite2 2016-05-10 Scientific Linux SLSA-2016:0594-1 graphite2 2016-04-06 Oracle ELSA-2016-0594 graphite2 2016-04-05 CentOS CESA-2016:0594 graphite2 2016-04-05 Red Hat RHSA-2016:0594-01 graphite2 2016-04-05 openSUSE openSUSE-SU-2016:0875-1 graphite2 2016-03-24 openSUSE openSUSE-SU-2016:0791-1 graphite2 2016-03-16 SUSE SUSE-SU-2016:0779-1 graphite2 2016-03-15 Ubuntu USN-2904-1 thunderbird 2016-03-08 SUSE SUSE-SU-2016:0564-1 firefox 2016-02-24 Debian DSA-3491-1 icedove 2016-02-24 SUSE SUSE-SU-2016:0554-1 firefox 2016-02-24 Fedora FEDORA-2016-4154a4d0ba graphite2 2016-02-21 Arch Linux ASA-201602-16 thunderbird 2016-02-21 Mageia MGASA-2016-0078 thunderbird 2016-02-17 Mageia MGASA-2016-0077 graphite2/firefox 2016-02-17 Ubuntu USN-2902-1 graphite2 2016-02-17 Scientific Linux SLSA-2016:0197-1 firefox 2016-02-16 Oracle ELSA-2016-0197 firefox 2016-02-16 Oracle ELSA-2016-0197 firefox 2016-02-16 Oracle ELSA-2016-0197 firefox 2016-02-16 CentOS CESA-2016:0197 firefox 2016-02-17 CentOS CESA-2016:0197 firefox 2016-02-17 CentOS CESA-2016:0197 firefox 2016-02-17 Debian DSA-3479-1 graphite2 2016-02-15 Red Hat RHSA-2016:0197-01 firefox 2016-02-16 Debian DSA-3477-1 iceweasel 2016-02-14

Comments (none posted)

mozilla: two vulnerabilities

Package(s):	firefox graphite	CVE #(s):	CVE-2016-1521 CVE-2016-1522
Created:	February 16, 2016	Updated:	February 17, 2016
Description:	From the CVE entries: The directrun function in directmachine.cpp in Libgraphite in Graphite 2 1.2.4, as used in Mozilla Firefox before 43.0 and Firefox ESR 38.x before 38.6.1, does not validate a certain skip operation, which allows remote attackers to execute arbitrary code, obtain sensitive information, or cause a denial of service (out-of-bounds read and application crash) via a crafted Graphite smart font. (CVE-2016-1521) Code.cpp in Libgraphite in Graphite 2 1.2.4, as used in Mozilla Firefox before 43.0 and Firefox ESR 38.x before 38.6.1, does not consider recursive load calls during a size check, which allows remote attackers to cause a denial of service (heap-based buffer overflow) or possibly execute arbitrary code via a crafted Graphite smart font. (CVE-2016-1522)
Alerts:	Gentoo 201701-63 graphite2 2017-01-24 Gentoo 201701-35 seamonkey 2017-01-13 Fedora FEDORA-2016-338a7e9925 graphite2 2016-05-10 Scientific Linux SLSA-2016:0594-1 graphite2 2016-04-06 Oracle ELSA-2016-0594 graphite2 2016-04-05 CentOS CESA-2016:0594 graphite2 2016-04-05 Red Hat RHSA-2016:0594-01 graphite2 2016-04-05 openSUSE openSUSE-SU-2016:0875-1 graphite2 2016-03-24 openSUSE openSUSE-SU-2016:0791-1 graphite2 2016-03-16 SUSE SUSE-SU-2016:0779-1 graphite2 2016-03-15 Fedora FEDORA-2016-4154a4d0ba graphite2 2016-02-21 Mageia MGASA-2016-0078 thunderbird 2016-02-17 Mageia MGASA-2016-0077 graphite2/firefox 2016-02-17 Ubuntu USN-2902-1 graphite2 2016-02-17 Scientific Linux SLSA-2016:0197-1 firefox 2016-02-16 Oracle ELSA-2016-0197 firefox 2016-02-16 Oracle ELSA-2016-0197 firefox 2016-02-16 Oracle ELSA-2016-0197 firefox 2016-02-16 CentOS CESA-2016:0197 firefox 2016-02-17 CentOS CESA-2016:0197 firefox 2016-02-17 CentOS CESA-2016:0197 firefox 2016-02-17 Debian DSA-3479-1 graphite2 2016-02-15 Red Hat RHSA-2016:0197-01 firefox 2016-02-16

Comments (none posted)

nghttp2: denial of service

Package(s):	nghttp2	CVE #(s):	CVE-2016-1544
Created:	February 15, 2016	Updated:	December 5, 2016
Description:	From the Arch Linux advisory: HTTP/2 uses HPACK to compress header fields. The basic idea is that HTTP header field is stored in the receiver with the numeric index number. The memory used by this storage is tightly constrained, and it is 4KiB by default. When sender sends the same header field, it just sends the corresponding numeric index number, which is usually 1 or 2 bytes. This means that after sender makes the receiver store the relatively large header field (e.g., 4KiB), and it can send specially crafted HEADERS/CONTINUATION frames which contain a lot of references to the stored header field, sender easily effectively send lots of big header fields to the receiver quite easily. nghttpd, nghttp, and libnghttp2_asio applications do not limit the memory usage for received header fields, so if the peer performs the procedure described above, they will crash due to out of memory. A remote attacker can cause an application using nghttp2 to allocate a lot of memory by sending specially crafted HTTP/2 frames, causing a denial of service.
Alerts:	openSUSE openSUSE-SU-2016:0675-1 nghttp2 2016-03-07 Gentoo 201612-13 nghttp2 2016-12-05 Fedora FEDORA-2016-3d9efe44d8 nghttp2 2016-02-22 Fedora FEDORA-2016-ac861a840e nghttp2 2016-02-17 Arch Linux ASA-201602-13 nghttp2 2016-02-13

Comments (none posted)

nodejs: two vulnerabilities

Package(s):	nodejs	CVE #(s):	CVE-2016-2216 CVE-2016-2086
Created:	February 15, 2016	Updated:	February 29, 2016
Description:	From the Red Hat bugzilla: CVE-2016-2216: It was reported that HTTP header parsing in Node.js is vulnerable to response splitting attacks. While Node.js has been protecting against response splitting attacks by checking for CRLF characters, it is possible to compose response headers using Unicode characters that decompose to these characters, bypassing the checks previously in place. CVE-2016-2086: A request smuggling vulnerability was found in Node.js that can be exploited under certain unspecified circumstances.
Alerts:	Gentoo 201612-43 nodejs 2016-12-13 openSUSE openSUSE-SU-2016:0604-1 nodejs 2016-02-29 Fedora FEDORA-2016-8925b6119f nodejs 2016-02-22 Mageia MGASA-2016-0080 nodejs 2016-02-19 Fedora FEDORA-2016-3102c11757 nodejs 2016-02-15

Comments (none posted)

pcre: multiple vulnerabilities

Package(s):	mingw-pcre pcre	CVE #(s):	CVE-2015-8395 CVE-2015-8392 CVE-2015-8388 CVE-2015-8385 CVE-2015-8384
Created:	February 17, 2016	Updated:	February 17, 2016
Description:	From the CVE entries: PCRE before 8.38 mishandles certain references, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror, a related issue to CVE-2015-8384 and CVE-2015-8392. (CVE-2015-8395) PCRE before 8.38 mishandles certain instances of the (?| substring, which allows remote attackers to cause a denial of service (unintended recursion and buffer overflow) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror, a related issue to CVE-2015-8384 and CVE-2015-8395. (CVE-2015-8392) PCRE before 8.38 mishandles the /(?=di(?<=(?1))|(?=(.))))/ pattern and related patterns with an unmatched closing parenthesis, which allows remote attackers to cause a denial of service (buffer overflow) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror. (CVE-2015-8388) PCRE before 8.38 mishandles the /(?|(\k'Pm')|(?'Pm'))/ pattern and related patterns with certain forward references, which allows remote attackers to cause a denial of service (buffer overflow) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror. (CVE-2015-8385) PCRE before 8.38 mishandles the /(?J)(?'d'(?'d'\g{d}))/ pattern and related patterns with certain recursive back references, which allows remote attackers to cause a denial of service (buffer overflow) or possibly have unspecified other impact via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror, a related issue to CVE-2015-8392 and CVE-2015-8395. (CVE-2015-8384)
Alerts:	Red Hat RHSA-2016:2750-01 rh-php56 2016-11-15 Gentoo 201607-02 libpcre 2016-07-09 Red Hat RHSA-2016:1132-01 rh-mariadb100-mariadb 2016-05-26 Oracle ELSA-2016-1025 pcre 2016-05-11 Scientific Linux SLSA-2016:1025-1 pcre 2016-05-11 Red Hat RHSA-2016:1025-01 pcre 2016-05-11 openSUSE openSUSE-SU-2016:3099-1 pcre 2016-12-12 Ubuntu USN-2943-1 pcre3 2016-03-29 Fedora FEDORA-2016-f59a8ff5d0 mingw-pcre 2016-02-17 Fedora FEDORA-2016-fd1199dbe2 mingw-pcre 2016-02-17

Comments (none posted)

postgresql: two vulnerabilities

Package(s):	postgresql-9.1, postgresql-9.3, postgresql-9.4	CVE #(s):	CVE-2016-0773 CVE-2016-0766
Created:	February 12, 2016	Updated:	March 3, 2016
Description:	From the Ubuntu advisory: It was discovered that PostgreSQL incorrectly handled certain regular expressions. A remote attacker could possibly use this issue to cause PostgreSQL to crash, resulting in a denial of service. (CVE-2016-0773) It was discovered that PostgreSQL incorrectly handled certain configuration settings (GUCS) for users of PL/Java. A remote attacker could possibly use this issue to escalate privileges. (CVE-2016-0766)
Alerts:	Gentoo 201701-33 postgresql 2017-01-13 SUSE SUSE-SU-2016:0677-1 postgresql94 2016-03-07 Scientific Linux SLSA-2016:0346-1 postgresql 2016-03-02 Scientific Linux SLSA-2016:0347-1 postgresql 2016-03-02 Oracle ELSA-2016-0346 postgresql 2016-03-02 Oracle ELSA-2016-0347 postgresql 2016-03-02 Mageia MGASA-2016-0085 postgresql 2016-03-02 CentOS CESA-2016:0347 postgresql 2016-03-02 CentOS CESA-2016:0346 postgresql 2016-03-02 Red Hat RHSA-2016:0348-01 rh-postgresql94-postgresql 2016-03-02 Red Hat RHSA-2016:0349-01 postgresql92-postgresql 2016-03-02 Red Hat RHSA-2016:0347-01 postgresql 2016-03-02 Red Hat RHSA-2016:0346-01 postgresql 2016-03-02 openSUSE openSUSE-SU-2016:0578-1 postgresql94 2016-02-25 Fedora FEDORA-2016-b0c2412ab2 postgresql 2016-02-25 Debian-LTS DLA-432-1 postgresql-8.4 2016-02-25 SUSE SUSE-SU-2016:0555-1 postgresql94 2016-02-24 Fedora FEDORA-2016-e0a6c9ebc4 postgresql 2016-02-23 SUSE SUSE-SU-2016:0539-1 postgresql93 2016-02-22 openSUSE openSUSE-SU-2016:0531-1 postgresql93 2016-02-21 Debian DSA-3476-1 postgresql-9.4 2016-02-13 Debian DSA-3475-1 postgresql-9.1 2016-02-13 Ubuntu USN-2894-1 postgresql-9.1, postgresql-9.3, postgresql-9.4 2016-02-11

Comments (none posted)

springframework-social: cross-site request forgery

Package(s):	springframework-social	CVE #(s):	CVE-2015-5258
Created:	February 17, 2016	Updated:	February 17, 2016
Description:	From the Red Hat bugzilla: It was found that when authorizing an application against an OAuth 2 API provider, Spring Social is vulnerable to a Cross-Site Request Forgery (CSRF) attack. The attack involves a malicious user beginning an OAuth 2 authorization flow using a fake account with an OAuth 2 API provider, but completing it by tricking the victim into visiting the callback request in their browser. As a consequence, the attacker will have access to the victim's account on the vulnerable site by way of the fake provider account.
Alerts:	Fedora FEDORA-2016-4d0e6ba888 springframework-social 2016-02-17

Comments (none posted)

xdelta3: code execution

Package(s):	xdelta3	CVE #(s):	CVE-2014-9765
Created:	February 16, 2016	Updated:	January 17, 2017
Description:	From the Debian LTS advisory: It was discovered that there was a buffer overflow in in xdelta3, a diff utility which works with binary files. This vulnerability allowed arbitrary code execution from input files.
Alerts:	Gentoo 201701-40 xdelta 2017-01-17 Mageia MGASA-2016-0084 xdelta3 2016-03-02 openSUSE openSUSE-SU-2016:0530-1 xdelta3 2016-02-20 openSUSE openSUSE-SU-2016:0524-1 xdelta3 2016-02-20 Debian DSA-3484-1 xdelta3 2016-02-19 Debian-LTS DLA-420-1 libmatroska 2016-02-18 Ubuntu USN-2901-1 xdelta3 2016-02-17 Debian-LTS DLA-417-1 xdelta3 2016-02-16

Comments (none posted)

Kernel release status

The current development kernel is 4.5-rc4, released on Valentine's day, February 14. Linus said: "So in between romancing your significant other, go out and test."

Stable updates: 4.4.2 and 3.14.61 were released on February 17. The 4.3.6 and 3.10.97 updates are in the review process as of this writing; they can be expected at any time. Note that 4.3.6 will be the final update in the 4.3 series.

Comments (none posted)

An in-kernel file loading interface

One of the many interesting aspects to kernel development is that much of the kernel's functionality is, itself, not available to the kernel. Most system calls are not intended to be called internally. Traditionally, this feature gap has extended to the reading of files from the filesystem, an act which tends to look like the implementation of policy within the kernel and, potentially, opens up security issues; thus it has long been discouraged.

Over time, though, we have seen the introduction of kernel code that does, indeed, read files. The first step in that direction was probably the in-kernel module loader, which replaced the user-space loader back in 2002. The module loader does not actually open files; it depends on user space to hand it a file descriptor corresponding to the module to be loaded. But, given that, it does read the module code directly, perform the necessary symbol resolution, and bind it into the kernel.

The door opened wider when the firmware-loading mechanism was moved in-kernel; in this case, the file containing the firmware is being opened by name from within the kernel. The integrity management architecture code also has to open files, and it seems likely that other uses will show up over time. Since there is no standard way to open and read a file within the kernel, there is a separate implementation for each of these users, each of which does things in its own way.

Mimi Zohar recently decided that it was time to make file reading a first-class supported operation within the kernel; the result is this patch set adding a common file loader. It makes this operation easier to perform, but, as will be seen, it still seems like it's not really meant for common use.

At the lowest level, Mimi's patch set adds a new function to read a file's contents into memory:

    int kernel_read_file(struct file *file, void **buf, loff_t *size,
		         loff_t max_size, enum kernel_read_file_id id);

This function will read the data from the open file indicated by file; up to max_size bytes will be read. It will allocate a buffer (using vmalloc()) to hold the file's contents, storing a pointer in *buf; the caller should free the buffer when it is no longer needed. The actual length of the file will be placed in *size. If the file is larger than max_size, nothing will be allocated or read, and -EFBIG will be returned.

The id argument is, arguably, where the interface (intentionally) loses a bit of generality. It is an enum type meant to indicate the purpose for which the file is being read; the values defined in the patch are READING_KEXEC_IMAGE, READING_KEXEC_INITRAMFS, READING_FIRMWARE, READING_MODULE, and READING_POLICY. The READING_POLICY option appears to be the motivation for the patch set; the IMA code can use it to read the policy and perform signature checking on the policy file. Developers wanting to use this interface will, most likely, have to add their own kernel_read_file_id constant to describe what they are doing.

There are a couple of helpers built on top of kernel_read_file():

    int kernel_read_file_from_path(char *path, void **buf, loff_t *size,
			       	   loff_t max_size,
				   enum kernel_read_file_id id);
    int kernel_read_file_from_fd(int fd, void **buf, loff_t *size,
    				 loff_t max_size, enum kernel_read_file_id id);

As might be expected, the first one opens and reads a file given its pathname, while the second takes an open file descriptor and reads from that.

One advantage to implementing this functionality in a single place is that it becomes possible to apply a uniform security policy in all settings where the kernel tries to read a file. To that end, Mimi's patch set adds two new security hooks (security_kernel_read_file() and security_kernel_post_read_file()) that can pass judgment on file-reading operations. The security_kernel_module_from_file() and security_kernel_fw_from_file() hooks have been removed in favor of the new hooks. This is the purpose of the kernel_file_read_id parameter described above; it is passed to the loaded security module(s) and can be checked by the current security policy.

This patch set has been through a few revisions and has gotten acknowledgments from a number of the relevant developers. At this point, there would appear to be few obstacles between it and the mainline kernel. So, in the near future, the kernel is likely to have a set of generic functions for opening and reading files, but any future users will have to tell the kernel what they are up to.

Comments (11 posted)

Netconf discussions, part 2

On September February 8 and 9, the Monday and Tuesday before the Netdev 1.1 conference in Seville, Spain, kernel networking developers gathered for Netconf, an informal roundtable to discuss recent issues face to face and to debate upcoming work. Last week, we covered the discussions that took place on the event's first day; what follows is a recap of how those discussions progressed on the second day.

SR-IOV

First, Alex Duyck raised the issue of supporting single-root I/O virtualization (SR-IOV), which is often employed to share a network interface device between virtual machines (VMs). The kernel has SR-IOV support for several devices, but there is no formal specification that the in-kernel implementations adhere to, which leads to increasing complexity. Intel and Mellanox devices operate differently, he said; in particular, some are capable of learning about the virtual network, while others need the hypervisor to explicitly pass down most configuration information.

There are also newer SR-IOV devices that include an embedded switch, which raises the question of whether all SR-IOV devices should be supported through the switchdev driver model. There is a case to be made that SR-IOV hardware, in general, mediates access between physical and virtual network devices, which is "switch-like," but not everyone is persuaded—Jesse Brandeburg said that Intel, for one, was not sure if it should take the switchdev approach. Networking subsystem maintainer David Miller, however, was strongly in favor of the approach. He noted that switchdev was intended to support a number of abstract models that amount to "packets flowing through non-net_device devices." He also pointed out that using switchdev would provide better netfilter support for SR-IOV.

eBPF

Alexei Starovoitov then provided an update on the extended Berkeley Packet Filter (eBPF). He highlighted, among other things, the BPF Compiler Collection (bcc) toolkit from IO Visor, the ability to attach eBPF programs to tracepoints, and the perf integration. These recent additions to eBPF have opened the door to significantly better tracing from user space, including better profiling of network performance. There is still more to be done in that area, however; he wants to add three or four new tracepoints in strategic places and to add some metadata to struct sock to eliminate the need for another lookup.

He also discussed upcoming changes and ideas for eBPF, starting with the ability to map eBPF maps into user-space memory with mmap(). That should make it possible to avoid locks and write zero-copy eBPF programs. He is also developing a kernel sampling counter that can be set from user space and used to collect periodic statistics. Further out, he would like to add eBPF support for generic segmentation offload (GSO) and generic receive offload (GRO) for UDP-based protocols like QUIC, which he hoped would discourage people from bypassing the kernel to implement new protocols in user space. He is also interested in adding support for bounded loops and vector instructions, he said, but he lacked time to explain the full rationale. He noted, however, that he has heard several use cases for those features, including vector instructions "which I first thought was crazy."

Starovoitov also proposed a different kind of "offload"—offloading the execution of eBPF programs to hardware. He knows of an implementation of eBPF that runs on a field-programmable gate array (FPGA), he said, which is reported to be released soon as open-source hardware. eBPF could also run on dedicated chips; the important thing is that the API remain stable and that the tool chain provide what developers need.

That change would make eBPF programs more like firmware, which several in the group seemed to regard as an unwise move. Miller, in particular, was not a fan of the concept, particularly since the eBPF virtual machine can run arbitrary code. That puts it in a different class than (for example) WiFi adapters, which load firmware designed to implement a well-known API. Jeff Kirsher noted that the debate was similar to the one over how much code should be offloaded from the kernel to switch hardware, and proposed tabling further discussion for now, to take up both topics together further down the line.

Replacing ethtool

Next, Brandeburg proposed writing a modernized replacement for the increasingly outdated ethtool network-interface control utility, most likely written on top of netlink. Because ethtool has numerous limitations, there is general agreement that a replacement is needed, although there are differing ideas about what constitute the critical features. Thomas Graf suggested that every operation should be split into a validation step and an execution step, thus making transactional operations possible. Shrijeet Mukherjee said that operations need to be asynchronous, in order to avoid locking when hundreds of commands are processed in short order—even on "read" commands, which are important to collecting high-quality statistics.

Mukherjee also suggested splitting such a replacement tool into a separate daemon and front-end, although Brandeburg and Graf both felt that such a split might be unwarranted. Miller observed that many people seem to want to query multiple hardware devices at the same time, so multi-device support should probably be made a design goal as well. Graf asked whether that included "multi-SET" commands to update several parameters at once; Miller replied that developers lives would be much easier if they do not try to support that model.

There was consensus that all of ethtool's existing functions map onto netlink functions, and that ethtool will likely never disappear completely. So a migration to the successor utility seems to be the path forward. Murkherjee noted that Cumulus has written a generic netlink front-end tool, and volunteered to release it as an RFC. Other than that, it may be a while before the plan takes solid form—although Brandeburg did suggest the name "nettool."

Devlink

Next, Jiří Pírko discussed devlink, a tool he has written to simplify the administration of physical hardware devices that provide more than one network port. Such devices include certain network interface cards (NICs), splitter cables for some newer NICs, and various application-specific integrated circuit (ASIC) switch devices. In each case, the hardware has device-wide capabilities a level above what the net_device interface provides. There is currently no generic solution to managing such devices; many of them also do not map easily to existing configuration tools.

Pírko had already posted an RFC about devlink to the mailing list, so he demonstrated it and fielded questions from around the room. Mukherjee worried that the tool was adding yet another command-line utility to what is already a lengthy list; Miller countered that a similar set of hurdles is already facing users who want to take advantage of the newer features in many WiFi chipsets.

In the end, however, Miller concurred that there is probably a need for some higher-level interface to these devices, and noted that it may overlap with user-space tools desired for switchdev. He also pointed out that the network developers have recognized the need for some higher-level object for quite some time. Known colloquially as "the thing," what this abstraction will eventually become is far from clear. But it is clear that the kernel is having to cope with configuring and managing devices above the "NIC level," so new tools will undoubtedly follow.

Lightweight tunnels and MPLS

Roopa Prabhu then spoke about lightweight tunnel (lwt) support. She noted that there are currently two distinct user classes for tunneling: those that make use of a net_device (such as VXLAN and GENEVE tunnels) and those that do not, instead redirecting packets via Multiprotocol Label Switching (MPLS) or Identifier Locator Addressing (ILA). The latter class constitutes the use case for lwt.

However, the redirection of lwt packets needs optimization. For instance, outgoing MPLS packets are redirected too early, before IP fragmentation is done. Incoming ILA packets, though, are redirected too late, after they are demultiplexed. In both cases, the timing of the redirection hurts throughput. Work is underway to fix the redirection examples cited, but Prabhu also suggested that it might be worth adding additional redirection hooks at other strategically placed points in the lwt-processing pipeline.

In addition, she reported on some other patches still in the works for MPLS. Included are additional statistics reporting, support for MPLS-based VPNs, ping and traceroute support, and hardware offload.

Netlink API

Prabhu then raised some potential improvements that could be made to the netlink API. A chief concern is how to extend the API as new functionality (such as switchdev) is merged into the kernel. Adding new attributes and extending existing attributes is not complicated, but the kernel does not return errors when it encounters an unknown attribute; it ignores them. Thus, users who copy and paste routing examples from kernel documentation end up with silent failures on later kernel releases, when the API has changed.

Several potential fixes to this problem were discussed, from providing a "features" bitmask that software could retrieve to examine the attributes available to exporting the entire network hierarchy (perhaps filtered by protocol). Prabhu also suggested writing an official set of guidelines documenting the use of the netlink API. Finally, she reported on some ongoing work; patches should be expected soon to provide IGMP and per–virtual-LAN statistics for bridges, and to add full support for netlink's bridge and bond attributes in iproute2.

Miller then asked whether it would ever be possible to get rid of the netlink mmap() functions, which are widely regarded as a failed experiment. The functionality is rarely—if ever—used, likely mmap()ing outgoing traffic makes it difficult to verify, although it does make dumps easier. The consensus seemed to be that the feature could be removed, since all user-space code would fall back onto the non-mmap() paths anyway.

APD and control protocols

Mukherjee then discussed Cumulus's work on adding support for ACPI Platform Description (APD) to the kernel. APD is not networking-specific, but it enables a "self-describing" infrastructure that the kernel could use to describe the available network hardware. The most important examples, he said, are the lane maps (that is, which lines are for transmit and which for receive).

He also reported on some work in progress to protect control protocols. Frequently, he said, when a control protocol misses its heartbeat, it will freeze up, which can trigger a cascade effect and "melt down the rest of the network." The team is currently exploring using deadline scheduling, so that if a heartbeat is missed, the kernel will treat it as a "hard miss" and take the network device offline.

Specifications

Miller asked the attendees whether the kernel community should write "NIC specifications" to tell hardware vendors what the kernel wants. Too often, it seems, network-device vendors expect to have easily accessible documents that describe the interfaces and behavior the operating system needs—largely because Microsoft was in the habit of publishing such specifications for Windows. The kernel community, however, has never had such documents, so even as Linux has supplanted Windows as the networking OS of choice, vendors have continued to design products around the Microsoft specifications.

The trick is deciding how the kernel community would write and publish such documents, as they do not fit into the kernel's established development process. But there was sufficient interest in the idea that it may be kicked around further. Herbert, for example, noted that during the recent effort to implement checksum offloading, it became apparent that none of the NIC vendors had heard of the kernel community's strong preference for a "generic" checksum feature rather than protocol-specific checksums. Had that information been better disseminated, perhaps more vendors would have implemented generic checksum offloading.

Netfilter

Pablo Neira Ayuso closed out the second day with a report on Netfilter. He highlighted a long list of enhancements made over the previous year, such as cleanups to bridge-netfilter, the addition of per-namespace netfilter hooks, and support for the new unified control group hierarchy. There have also been many improvements to nftables over the same time period, including the addition of garbage collection, generic packet mangling, a new tracing infrastructure, and the ability to set timeouts.

He also reported on the addition of switchdev support in the nf_tables kernel module, which allows the user to offload network access-control lists (ACLs) to switch hardware. The idea is to provide a netlink front-end for creating rulesets, which are mapped to an intermediate representation (IR); the IR will then be pushed to the switch device driver, which is responsible for converting the IR into the necessary internal representation. The goal is to maintain compatibility between rulesets written for software nf_tables and for devices with hardware offload. Daniel Borkmann asked if the IR could be used to generate eBPF programs; Neira replied that it has been discussed, but that such an effort is not yet underway.

Finally, he discussed some ongoing work. Command autocompletion is being added to the nftables user-space tool, along with support for the new tracing infrastructure. Connection tracking will be added for bridge filtering, and several new features are in the works for the ingress hook (including connection tracking, logging, and queueing). There is also a high-level library under development, although it is still experimental at this stage; Neira said that the project was in no rush to publish it as of yet.

After the last presentation, Miller wrapped up the day by expressing thanks to the organizers and to each of the presenters. The attendees gathered for a group photo, then dispersed to prepare for the coming three days of the Netdev conference.

[The author would like to thank the Netconf and Netdev organizers for travel assistance to Seville.]

Comments (2 posted)

The switchdev driver model

Over the years, Linux has grown to a position of dominance in many branches of computing, but there are still niche markets—some of them surprising—where it has yet to make a serious impact. One of those markets is in high-end networking hardware: the managed switches and high-density routers that connect many large-scale networks or data centers. Such hardware is often marketed as "Linux capable" or "built with Linux" but, in reality, has its functionality implemented only in a proprietary blob. In 2015, that situation led the kernel networking developers to adopt a new driver model called switchdev that is aimed at replacing those proprietary blocks with standard kernel interfaces. Early on, it may have seemed like a rather speculative move, but at the Netdev 1.1 conference in Seville, Spain, switchdev was front and center.

The market for the switches in question is dominated by a few companies: Cisco is the largest vendor by a comfortable margin, followed by Arista, Juniper, and several other smaller companies. These appliance vendors often advertise Linux support for their products, but the model they employ is, at best, a small Linux system connected to a proprietary application-specific integrated circuit (ASIC) that actually handles all packet processing in hardware. The Linux system boots to a shell prompt, where proprietary command-line utilities are used to manipulate the switch chip. Furthermore, those utilities are generally built around a binary-blob "software development kit" (SDK) provided by the chip vendor. Thus, for Linux to break through the appliance vendor's lock-in, the chip vendor's lock-in must be broken as well.

The design of switchdev originates in Open vSwitch project, and was first described by Jiří Pírko in a September 2014 patch. At the Netdev 0.1 conference in February 2015, the networking developers decided to expand and adopt switchdev as a general solution for hardware switch chips and to make a concerted effort to break the binary-blob "SDK" stranglehold.

An overview of switchdev can be found at Documentation/networking/switchdev.txt. Each physical port on a device is registered with the kernel as a net_device, as is done for existing network interface cards (NICs). Ports can be bonded or bridged, tunneled or divided into virtual LANs (VLANs) using the existing tools (such as bridge, ip, and iproute2). The advantage of a switchdev driver is that such switching constructs can be offloaded to the switch hardware. As such, the driver mirrors each entry in the forwarding database (FDB) down to the hardware, and monitors for changes.

The kernel's netlink facility issues a NETDEV_CHANGEUPPER notification whenever there is a modification to the "upper" (that is, software) side of the mapping, so that the driver can make the corresponding adjustment to the "lower" (that is, hardware) side. That allows users to manage the switch hardware with the standard complement of tools. On the flip side, switch hardware is also often capable of learning about the network, such as which MAC addresses are found on which VLAN/port combinations. The driver sends a notification (for example, SWITCHDEV_FDB_ADD when it learns a new {port, MAC, VLAN} tuple), which is then used to update the FDB.

Up until now, much of the emphasis has been on modeling layer-2 (Ethernet) switching in switchdev, but layer-3 (IP) offload is supported as well for devices that perform IP routing. Currently, that support is limited to IPv4, but IPv6 support is in the works.

Initially, the only device supported by switchdev was the "rocker" software switch for QEMU. But, in July 2015, support was introduced for the Mellanox SwitchX-2 ASIC. Mellanox has continued to fund in-kernel driver development since. At the low end of the spectrum, Broadcom BCM53xx switches (typically found in home router hardware) gained switchdev support, too, although the emphasis remained on the large switch devices and the vendors of the chips within.

As our coverage of the 2016 Netconf meetings (part 1, part 2) notes, switchdev is increasingly the layer at which new kernel networking features are being planned—such as single-root I/O virtualization (SR-IOV) or Virtual Routing and Forwarding (VRF). But in-kernel usage of the API and a single chip vendor hardly equates with breaking the existing switch-vendors' logjam.

What is significant, however, is a major telecom carrier throwing its weight behind switchdev. Damascene Joachimpillai from Verizon did just that in his keynote talk at this year's Netdev. Joachimpillai (or "DJ" as he is know around the community) runs the Network Architecture team for the network-applications division inside Verizon—the group that develops and deploys the carrier's own mobile apps, for everything from contacts synchronization to video streaming. The division runs several data centers in the United States, he said, but it is the switches and other "middle boxes" that impose the most significant requirements, rather than the servers.

To that end, he has grown dissatisfied with the user-space network-configuration tools provided by most switch vendors, and is backing switchdev development. Several dozen switches that each require a separate CLI application for management becomes a support nightmare, he said. Primarily, that is because the proprietary CLI tools do not make it easy to automate operations; his division needs to adjust network policies on the fly to adapt to changing traffic. The switch vendors are typically reluctant to make programmatic interfaces to their tools, and even those that do, he said, seem to change those interfaces with each product release.

Joachimpillai took numerous questions from the audience, most of which dealt with what a large carrier wants to see from switchdev and from the kernel in general. In reply, he cited uniformity as a critical feature, in contrast to the ever-changing interfaces of proprietary switch vendors' tools. He also noted that hardware offload was vital, and that Verizon tends to purchase hardware that can be upgraded later in the field. He hopes to choose hardware today, he said, that has good software support for features now that will be hardware-accelerated in future kernels.

An audience member asked whether Joachimpillai's division was doing any kernel development internally, or if using existing knobs was sufficient. He replied that, so far, the team has just been working with outside developers who were already working on projects that it was interested in. The kernel community has been quite responsive to change requests so far, he added, in particular with its recent work on improving IPsec support.

Throughout the rest of Netdev, it was clear that Verizon's endorsement of switchdev was seen as a big win for the project. Whether it prompts any proprietary switch vendors to open up their product lines certain remains to be seen—although, on the following day, Intel developers did announce that the company would be writing switchdev drivers for its own switch chips.

Together, Mellanox and Intel still only account for a fraction of the overall switch device market, but their migration to switchdev is likely to influence other small vendors in the short term. And, if big customers like Verizon start purchasing switch hardware based on switchdev support, the proprietary switch vendors will surely begin to feel the heat.

[The author would like to thank the Netconf and Netdev organizers for travel assistance to Seville.]

Comments (none posted)

CopperheadOS: Securing the Android

The beta release of the CopperheadOS distribution was announced on February 8. CopperheadOS is an Android variant that is aimed at users who take security seriously. A look at this distribution's features shows some of the things that can be done to increase the security of a stock Android installation.

Where to start?

When building an Android-based system, one of the first questions to answer is: which system should one start with? When the alpha release was announced, CopperheadOS was based on the CyanogenMod 12.1 branch. As of the beta, however, things have changed; CopperheadOS is now based directly on the Android Open Source Project (AOSP) release. That is a significant change, but the developers are clear on their reasons for making it:

One unfortunate effect of this change for some users is that the number of supported devices has dropped; the beta is only available for Nexus 5, 5X, and 9 devices, with Nexus 6/6P planned for "some point down the road". Expanding the hardware range further is likely to be challenging given amount of proprietary software required to make each new platform work. The CopperheadOS developers do not say so anywhere, but it seems likely that they are hoping to be able to work with handset vendors in the future, once they have a viable distribution to offer.

PaX and Zygote

CopperheadOS starts with AOSP, but makes a number of changes aimed at improving the security of the system; one of the first of those is to apply the PaX security patches. One of the key benefits that comes from PaX is strengthening Android's resistance to executing code that happens to find its way into writable memory. Android makes extensive use of just-in-time compilation, making this task harder, but the CopperheadOS developers were still able to make some progress; see this page for details on what they have done.

Another area of work is address-space layout randomization (ASLR). Android already makes heavy use of ASLR; indeed, recent patches aimed at increasing ASLR entropy came from Google. But there is an interesting and potentially fatal flaw in the form of Android's "Zygote" mechanism. Starting up a Java executable can require loading a lot of class modules, which takes time; replicating that loaded code across each process can also consume a lot of memory. Zygote addresses these problems by having a single process that loads all of the class libraries. When it is time to launch a new app, the Zygote process forks, then begins running the app code directly (without an exec() call).

This model is certainly efficient, in that new apps can launch quickly and they will have all the needed classes already loaded and ready to go; those classes also need only be stored in memory once. The problem with taking away the exec() stage, though, is that it defeats ASLR; every app running on a given system will have the same randomization offsets. An attacker who is able to run an app on a targeted system, or who can extract the layout information from a running app, will know the layouts used for all running apps, present and future.

The solution used in CopperheadOS is to restore the exec() call to the Zygote app-launch mechanism. That slows down the launch noticeably, but the result is still said to be "fast enough for the niche". There is also an increase in memory use, though that isn't necessarily a huge problem on contemporary devices. In the future, CopperheadOS may adopt the "Morula" approach described in this paper [PDF]; it works, once again, by creating each app process with exec(), but it aims to reduce the startup latency by creating and initializing new processes in the background before apps are launched. When the time comes to launch a new app, one of the existing processes reads and runs the code much like the existing Zygote system, but it is running with its own set of ASLR offsets.

Other enhancements

There has been some work done to harden the Bionic C library used by Android. That includes instrumenting a number of functions (mostly system call wrappers) with the _FORTIFY_SOURCE option to prevent buffer overflows. Happily, much of this work has been submitted to and accepted by AOSP, so it will eventually appear in regular Android releases as well. The malloc() implementation has been torn out and replaced with the OpenBSD version, which features better layout randomization. This allocator also overwrites data when chunks of memory are freed. Guard pages and additional randomization have been applied to stacks; this work, too, has been sent upstream.

One of the claimed features is MAC-address randomization, making it difficult to track a device from one access-point connection to the next. As of this writing, though, that feature has been disabled after showing an unpleasant tendency toward breaking WiFi connections altogether.

Another significant change is to separate the password used to encrypt storage from the one used to unlock the device. That allows the unlocking password to be relatively simple, while the encryption password can be obnoxious and difficult to guess. After five failed attempts to unlock the device, a reboot will be forced, causing any attacker to be confronted with the (presumably stronger) encryption password.

CopperheadOS, like CyanogenMod, comes without Google Play Services and the associated apps. Instead, it has F-Droid installed — a solution that will be sufficient for some users, but not for others. Those needing the Google apps can download a separate bundle and install them much like CyanogenMod users do. It's worth noting (as was done in this tracker issue) that even a system without the Google apps will make occasional connections to Google servers; there are currently no plans to change that behavior.

Giving it a try

Installation of CopperheadOS onto a Nexus 5 handset is a relatively straightforward affair. The bootloader must be unlocked, of course, if that has not been done so far; that leads to that moment where one has to be absolutely sure of having backed up everything of interest on the device. The actual installation appears to have reused the mechanism provided with the stock Android images; one needs only plug in a phone running in the bootloader and fire off the provided flash_all.sh script. A few minutes later, the phone boots into CopperheadOS.

Anybody looking for something shiny and new is going to be disappointed, though; the nature of this distribution is to make changes that are not really visible. The one thing that does stand out — the lack of Google apps — is not hugely impressive. Those apps can be installed (using the packages that circulate for CyanogenMod installations), but the user is left to figure that out on their own; it is clearly not a priority for the CopperheadOS developers. Of course, if one is installing a hardened distribution like this, it is worth asking whether installing the whole Google apps ecosystem is in line with one's security requirements.

The distribution functions like an ordinary system for the most part. The startup latency caused by the Zygote changes were difficult to notice; those changes seem like a good tradeoff on a device like this. One non-repeatable app crash was observed while playing with the system — something that is far from unheard-of on regular Android. CopperheadOS seems to be a working Android build; whether it truly meets its security goals is, naturally, a bit harder to judge.

Keeping current

A secure device operating system will not stay that way without regular updates. CopperheadOS includes an over-the-air update mechanism with, as evidenced by the downloads page, frequent updates going out. Being based on AOSP should allow CopperheadOS to use the updates now produced regularly for Android, but the project appears to be creating its own updates more frequently than that. Updates are signed, so it should not be possible for a random attacker to push a malicious update into a system.

On the surface, CopperheadOS appears to have done a lot of things right. It offers a distribution that looks a lot like pristine AOSP, but with a lot more security built-in. The developers appear to have taken an upstream-friendly approach to their work, pushing at least some of it back into AOSP. The Android developers are already concerned about security, but there is certainly room for a variant catering to users who want an even sharper focus in that area.

If there are concerns to be raised, they are around sustainability. Developing this distribution and supporting it with updates requires a fair amount of time and resources. It seems clear that the CopperheadOS developers would like for this project to fund their work; their web site talks about selling phones with CopperheadOS installed, for example. If they succeed, then this distribution should have a bright economic future and, hopefully, a bright community-oriented future as well. Otherwise the whole thing is likely to fade away, with users perhaps not noticing until it occurs to them to wonder why they haven't seen an update for a while. But that is a risk inherent to most projects, and to many commercial products as well. For now, it is good to see this kind of work being done.

Comments (1 posted)

Distribution quote of the week

-- Ikey Doherty

Comments (none posted)

Debian 6.0 Long Term Support reaching end-of-life

The Debian LTS team has announced that Debian 6.0 ("squeeze") support will reach its end-of-life on February 29, 2016, five years after its initial release on February 6, 2011. "The LTS Team will prepare the transition to Debian 7 ("wheezy"), which is the current oldstable release. The LTS team will take over support from the Security Team on April 26, 2016. Debian 7 will also receive Long Term Support for five years after its initial release with support ending in May 2018."

Full Story (comments: none)

Fedora support for Vulkan

Fedora has announced support for Vulkan, the new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs. "Or: Vulkan is to OpenGL as Wayland is to X11. It does many of the same things, but - with the benefit of a few decades of experience - it's a much better match for both the hardware it targets, and the applications trying to use the hardware."

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 648 (February 15)
• Tails Report (September to December 2015 - published February 13)
• Ubuntu Weekly Newsletter, Issue 454 (February 14)

Comments (none posted)

Is PCLinuxOS Is the Best Rolling Release Distro? (Datamation)

Datamation has a review of PCLinuxOS KDE edition. "Normally I associate KDE with features, not speed. Yet I've found that PCLinuxOS running KDE is very responsive. Menus just pop open without delay. I can bounce through the settings quickly and without any lag whatsoever. And considering this is on an Intel Atom CPU (what I had available for testing), that's really saying something. I also found the boot-up time to be more than acceptable. And thanks to being able to configure my boot loader choices from the start, the process was as streamlined as I wanted it to be. I've used PCLinuxOS in the past, so I'm familiar with how dependable it is. With the exception of an application crashing for whatever reason, I've found the desktop environment quite stable. This was also true, even after 900 updates! And with this track record, you only need to tie in the reality that you won't ever have to re-install again baring a hard drive failure. It's a fairly attractive option when you consider this fact."

Comments (none posted)

The Vulkan graphics API

The Khronos Group, which (among other things) maintains the OpenGL specification, has released version 1.0 of its new cross-platform graphics API, Vulkan. The Vulkan API is designed to be a lightweight API—at least in comparison to OpenGL—that provides graphics processing and general-purpose GPU computation. A number of open-source projects have announced Vulkan support already, although it may be some time before it can be put to the test in a major way on the average Linux system. In the long run, however, Vulkan promises higher performance on modern GPU hardware, simplified driver development, and a single API that covers all device profiles, from embedded systems to desktops.

Many of the ideas in Vulkan originated in AMD's Mantle API project, which was started in 2013, but shut down in 2015. Mantle was, understandably, an AMD-only effort, but its goals were of interest to graphics-software developers on many hardware platforms: build an OpenGL-like API from the ground up that dispensed with years' worth of legacy architecture no longer applicable on modern hardware.

For Linux users, the parallels to Wayland and X11 are clear. As with X, OpenGL was initially devised for hardware and software stacks that look very different from what is commonly deployed today. The Vulkan project targeted the same ideal as Mantle and eventually incorporated much of AMD's work on the subject. Still, Khronos took Vulkan from inception to a first release in a relatively fast 18 months, delivering drivers, demo code, and open-source software-development kits (SDKs) in conjunction with the specification.

What's available

The specification itself is available on the Khronos site as well as in a GitHub repository. The drivers available at launch time include offerings from a variety of companies that cover desktop and embedded Linux, Windows, and Android. On the desktop Linux side, Intel has released drivers for its fifth- and sixth-generation Core processors; NVIDIA has released drivers for the Kepler and Maxwell GPU families (essentially the GeForce 600 and later). For Android and embedded systems, Qualcomm has published a driver for the Adreno 530 GPU (found in the Snapdragon 820), and Imagination has developed drivers for PowerVR. So far, AMD has only released a Windows driver.

The NVIDIA drivers are proprietary, and available for both 64-bit and 32-bit systems. The Intel drivers are free software; they are available in the Mesa Git repository and have been packaged for Ubuntu and Fedora. Apart from the drivers themselves, Vulkan defines a Window System Interface (WSI) that provides hooks for various window systems. Included in the 1.0 WSI specification are Wayland, X11, Mir, and Android. There are two SDK options available; one is the official Vulkan offering from LunarG and includes desktop Linux and Android, the other is Google's Android Native Development Kit (NDK), which now includes Vulkan support.

In addition, support has already begun trickling into other libraries. Matthew Waters announced a GStreamer video sink element that uses Vulkan.

What's inside

With all of that code available, the natural question to ask is what Vulkan 1.0 provides that OpenGL does not. In a sense, Vulkan is designed to be a successor to OpenGL, offering a cross-platform interface to GPUs for 3D rendering, video and graphics processing, and parallel computing. In another sense, though, Vulkan is positioned to serve as an OpenGL alternative that is tailored to use cases that need to squeeze as much performance out of the hardware as possible. For those applications, ditching OpenGL's overhead is paramount. For other programs, however, Vulkan's stripped-down design means considerably more work.

There are four large pieces of the OpenGL specification that are cut away in Vulkan: memory management, error handling, validation, and diagnostics. Strictly speaking, the validation and diagnostic layers are optional in Vulkan, but for performance-sensitive applications, the inability to run without them in OpenGL was a drawback. Dispensing with built-in memory management and error handling places a heavier burden on the application but, in turn, it removes the OpenGL-context management and memory management code from the graphics driver.

In addition, Vulkan is designed to support multi-core CPUs with full multithreading. In Vulkan, threads can each create their own command buffer, and all of the buffers feed into the same queue. Here again, the application is responsible for its own synchronization and thread management, but OpenGL is hampered by the need to maintain a single context, which can leave CPU cores sitting idle.

For a lot of GPU-intensive use cases, the critical part of an OpenGL application is the shader, the program that runs on the GPU itself. OpenGL required that shaders be written in a device-independent language called OpenGL Shading Language (GLSL), in source form. The OpenGL driver was required to compile the GLSL into machine code for the device, thus both making the driver more complicated and making it impossible to pre-compile the shader.

Vulkan replaces GLSL with an intermediate representation called Standard Portable Intermediate Representation (SPIR). Shaders can be written in any language and compiled to SPIR offline. Earlier revisions of SPIR were designed to be compatible with the LLVM compiler's intermediate representation, although the current version, SPIR-V, no longer maintains that compatibility guarantee. The SPIR-V tools support compiling Open Compute Language (OpenCL) kernels as well as GLSL shaders. Finally, Vulkan offers only a single API, which is shared by the desktop, Android, and embedded platforms. Thus, there should not be a need for developers to wrangle OpenGL and OpenGL ES for a single application.

What next

At this point, applications that need to drive as much performance as possible out of the available hardware will likely find Vulkan an easier API than OpenGL for optimizing GPU performance. The primary use case thus far seems to be the gaming market; it is no coincidence that Valve (developers of the Steam game-distribution service) funded the development of the Vulkan SDK.

But the smaller or simpler an application is, the less appealing it will be to handle GPU memory allocation and error handling internally. In its press materials, the Khronos Group touts that Vulkan will attract a rich ecosystem of libraries and frameworks that provide the higher-level functionality encoded in the OpenGL specification but omitted from Vulkan. That is likely the case, particularly if OpenGL is destined to be phased out. But, for now, the further away one gets from the GPU hardware, the less Vulkan has to offer. Simpler drivers are, no doubt, a win, as is support for multithreading. The performance gains of switching to Vulkan, though, are likely reserved for gaming engine developers in the near term.

Comments (1 posted)

Quotes of the week

— Benjamin Mako Hill, on the recent settlement agreement poised to declare the song "Happy Birthday" in the public domain.

— Christian, commenting on Martín Ferrari's "rage post" about the Node.js approach to packaging.

Comments (2 posted)

Announcing Vulkan 1.0

Vulkan is a new graphics API specification, seemingly meant to supersede OpenGL. Collabora has announced the availability of the 1.0 specification — and that the Wayland compositor already supports it. "To provide the best possible base for fluid modern user interfaces, Collabora have worked extensively on the Wayland window system, the underlying Kernel Mode Setting drivers and atomic modesetting, and also the EGL specifications and implementations. We are proud to continue this work with Vulkan." Intel has announced an open-source Vulkan driver for its hardware as well.

Comments (26 posted)

Go 1.6 released

Version 1.6 of the Go programming language has been released. The most significant change is the addition of support for HTTP/2, which is enabled by default. There have also been changes to templates, changes to the rules for sharing pointers between Go and C code, and many other small updates.

Comments (none posted)

systemd v229 released

Version 229 of systemd has been released. The update includes the addition of DNSSEC support (among other features) to the systemd-resolved name-resolution service, a reworked coredump-collection feature, and numerous changes to other components.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (February 12)
• What's cooking in git.git (February 17)
• LLVM Weekly (February 15)
• OCaml Weekly News (February 16)
• OpenStack Developer Digest (February 12)
• Perl Weekly (February 15)
• PostgreSQL Weekly News (February 14)
• Python Weekly (February 11)
• Ruby Weekly (February 11)
• This Week in Rust (February 15)
• Tahoe-LAFS Weekly News (February 12)
• Tor Weekly News (February 15; returning after a multi-month hiatus)
• Wikimedia Tech News (February 15)

Comments (none posted)

Is the vinyl LP an open music format? (Opensource.com)

Chris Hermansen looks at an early open music format—vinyl LP records—over at Opensource.com. He goes into some of the details of the format and how it is read, as well as a bit about ripping records using Linux. "Ok, so we just figured out that our stylus puts 136 times as much pressure on our records as our car puts on the pavement? That's crazy!!! Why doesn't the stylus completely destroy the record? Those alternate-Earth physicists and engineers are rolling on the floor now, clutching their bellies and gasping for breath... but here is the final straw. Despite the seemingly ridiculous or even impossible nature of the whole ensemble of components, a well-recorded vinyl LP played back with a decent turntable, tonearm, and cartridge sounds wonderful."

Comments (101 posted)

D’Souza: Maru is open source!

On the Maru blog, developer Preetam D’Souza has announced that the Maru project is now open source. Maru is a desktop system running on a smartphone, so that adding a display, keyboard, and mouse to a phone allows the user to run their desktop on the phone—and still be able to use the device as a phone. "I’ve gotta say, the open source community never ceases to amaze me. I’ve had emails from people asking if they can help test Maru on other devices on a Sunday. How many normal people do you know that willingly want to give up their Sundays to help test software? I’ve experienced this helpfulness time and time again, whether it was the speakers at open source conferences so willing to share their knowledge, or the folks on forums who were so keen to help out beginners like me. Maru would never have been possible without that spirit of openness."

Comments (3 posted)

Chapman: Unlocking my Lenovo laptop

In a lengthy blog series (part 1, part 2, and part 3), Matthew Chapman described the process of getting a non-Lenovo battery to charge in his Thinkpad laptop. He reverse-engineered the authorization that real batteries do and changed the code in the embedded controller (EC) on the laptop to allow other batteries to charge. "I look in BIOS to see where these messages are coming from. Both this message and the original unauthorised battery message are displayed by LenovoVideoInitDxe.efi: don’t ask me why this code is in this module rather than somewhere more relevant (may I suggest LenovoAnnoyingBatteryMessageDxe.efi?), but it might have been convenient to put it in the video initialisation module as the message is displayed when the screen is cleared post-POST [Power-on self-test]." (Thanks to Neil Brown.)

Comments (18 posted)

Wielaard: Looking forward to GCC6 – Many new warnings

Mark Wielaard writes about some of the many new compiler warnings provided by the GCC6 release. "My favorite is still -Wmisleading-indentation. But there are many more that have found various bugs. Not all of them are enabled by default, but it makes sense to enable as many as possible when writing new code."

Comments (80 posted)

Remembering Thomas Wood

The GNOME project mourns the passing of Thomas Wood, commonly known as ‘thos’ on irc. "Thomas was a long time contributor to the GNOME Art project, where he curated GTK+ Themes, backgrounds, login screens, and icons. In later years, he also worked on the control center and maintained the GNOME Backgrounds module. Outside of GNOME, he worked on the Moblin platform, which enabled various technologies key to GNOME 3, like GNOME Shell and Clutter."

Comments (none posted)

FSF fundraiser a success

The Free Software Foundation has announced that its winter fundraiser was a success, raising $452,000 and gaining 495 new members. "In addition to feeling humbled by your generosity, we get some heartening takeaways from those numbers. More people than ever are supporting the FSF's work defending user freedom -- in addition to welcoming more new members than in any previous fundraiser, more people gave, and gave more generously, than in the past."

Full Story (comments: none)

Secret Lab: It's OK to abandon your project (Opensource.com)

Opensource.com covers a linux.conf.au talk by Paris Buttfield-Addison and Jon Manning of Secret Lab. "Secret Lab participates in hackathons to subtly subvert that mission by making interesting games based on data. They don't even care if anyone ever plays the game again. But they've won quite a few national awards along the way. In particular, they've done so through participation in several GovHack events, which are Australia/New Zealand hackathons built around government data sources."

Comments (none posted)

CFP Deadlines: February 18, 2016 to April 18, 2016

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
February 23	April 9 April 10	OSS Weekend	Bratislava, Slovakia
February 28	April 6	PostgreSQL and PostGIS, Session #8	Lyon, France
February 28	May 10 May 12	Samba eXPerience 2016	Berlin, Germany
February 28	April 18 April 19	Linux Storage, Filesystem & Memory Management Summit	Raleigh, NC, USA
February 28	June 21 June 22	Deutsche OpenStack Tage	Köln, Deutschland
February 28	June 24 June 25	Hong Kong Open Source Conference 2016	Hong Kong, Hong Kong
March 1	April 23	DevCrowd 2016	Szczecin, Poland
March 6	July 17 July 24	EuroPython 2016	Bilbao, Spain
March 9	June 1 June 2	Apache MesosCon	Denver, CO, USA
March 10	May 14 May 15	Open Source Conference Albania	Tirana, Albania
March 12	April 26	Open Source Day 2016	Warsaw, Poland
March 15	April 28 May 1	Mini-DebCamp & DebConf	Vienna, Austria
March 20	April 28 April 30	Linuxwochen Wien 2016	Vienna, Austria
March 25	July 11 July 17	SciPy 2016	Austin, TX, USA
April 1	May 26	NLUUG - Spring conference 2016	Bunnik, The Netherlands
April 2	May 2 May 3	PyCon Israel 2016	Tel Aviv, Israel
April 7	April 8 April 10	mini Linux Audio Conference 2016	Berlin, Germany
April 8	August 2 August 5	Flock to Fedora	Krakow, Poland
April 15	June 27 July 1	12th Netfilter Workshop	Amsterdam, Netherlands
April 15	June 22 June 26	openSUSE Conference 2016	Nürnberg, Germany

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

MiniDebConf at FOSSASIA

There will be a MiniDebConf at FOSSASIA 2016 in Singapore. FOSSASIA will be held March 18-20. "Please note that the extent of Debian's participation at this event will depend on the number of volunteers. There is sufficient commitment for talks to go ahead in a room dedicated to Debian and for a table where Debian-related materials can be distributed with or without volunteers present."

Full Story (comments: none)

Vault Storage Conference Program Announced

Vault, the Linux storage and filesystems conference, will be held April 20-21 in Raleigh, NC. The lineup of keynote speakers and educational sessions for Vault have been announced.

Full Story (comments: none)

EuroPython 2016

EuroPython will take place July 17-24 in Bilbao, Spain. The conference website has been launched.

Full Story (comments: none)

Events: February 18, 2016 to April 18, 2016

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
February 24 February 25	AGL Member's Meeting	Tokyo, Japan
February 27	Open Source Days	Copenhagen, Denmark
March 1 March 6	Internet Freedom Festival	Valencia, Spain
March 1	Icinga Camp Berlin	Berlin, Germany
March 8 March 10	Fluent 2016	San Francisco, CA, USA
March 9 March 11	18th German Perl Workshop	Nürnberg, Germany
March 10 March 12	Studencki Festiwal Informatyczny (Students' Computer Science Festival)	Cracow, Poland
March 11 March 13	Zimowisko Linuksowe TLUG	Puck, Poland
March 11 March 13	PyCon SK 2016	Bratislava, Slovakia
March 14 March 17	Open Networking Summit	Santa Clara, CA, USA
March 14 March 18	CeBIT 2016 Open Source Forum	Hannover, Germany
March 16 March 17	Great Wide Open	Atlanta, GA, USA
March 18 March 20	FOSSASIA 2016 Singapore	Singapore, Singapore
March 19 March 20	Chemnitzer Linux Tage 2016	Chemnitz, Germany
March 19 March 20	LibrePlanet	Boston, MA, USA
March 23	Make Open Source Software 2016	Bucharest, Romania
March 29 March 31	Collaboration Summit	Lake Tahoe, CA, USA
April 1	DevOps Italia	Bologna, Italy
April 4 April 6	Web Audio Conference	Atlanta, GA, USA
April 4 April 6	Embedded Linux Conference	San Diego, CA, USA
April 4 April 6	OpenIoT Summit	San Diego, CA, USA
April 4 April 8	OpenFabrics Alliance Workshop	Monterey, CA, USA
April 5 April 7	Lustre User Group 2016	Portland, OR, USA
April 6	PostgreSQL and PostGIS, Session #8	Lyon, France
April 7 April 8	SRECon16	Santa Clara, CA, USA
April 8 April 10	mini Linux Audio Conference 2016	Berlin, Germany
April 9 April 10	OSS Weekend	Bratislava, Slovakia
April 11 April 13	O’Reilly Software Architecture Conference	New York, NY, USA
April 15 April 17	PyCon Italia Sette	Firenze, Italia
April 15 April 17	Akademy-es 2016	Madrid, Spain
April 15 April 18	Libre Graphics Meeting	London, UK
April 16	15. Augsburger Linux Info Tag	Augsburg, Germany

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