Cory Doctorow on the game plan to crush DRM

Author and Electronic Frontier Foundation (EFF) activist Cory Doctorow presented the opening keynote at SCALE 14x in Pasadena on January 22, using the opportunity to highlight the project that brought him back to the EFF after a decade. That project is Apollo 1201, an effort to challenge the ever-expanding problem of "digital rights management" (DRM)—now built into all manner of mass-produced products, not just entertainment media—that threatens the rights of individuals. The dangers of DRM are even greater than those posed by traditional proprietary software, Doctorow said, precisely because the rise of "smart" devices is putting DRM-locked software everywhere around us.

Doctorow told the audience that the fight against proprietary software has taken place on four fronts, which correspond to the factors Lawrence Lessig says regulate behavior: "code," "markets," "norms," and "laws." The "code" front is seen, simply enough, in Apache unseating IIS because Apache was a better web server. The "market" front is where open source creates new business opportunities that would not exist otherwise and the popularity of the new market overwhelms the proprietary software. Samba is an example, he said: it made SMB shares more useful and spawned new products; the popularity of those products took Microsoft out of the driver's seat. The "norm" front is ethical and moral debates, where advocacy changes the minds of the public. And the "laws" front involves all of the instances where city, regional, or national governments have passed laws mandating open-source software, open data, and the like.

Those four fronts describe the competition between "open" and "closed" technology in recent years, Doctorow said, but there is "a more profound kind of 'proprietary' on the horizon" now—one that goes beyond whether or not a product is "open" or "free." The new form of proprietary is code that includes DRM, which is much harder to fight against.

"You all know the DMCA [Digital Millenium Copyright Act]," he said. "It's the author of all your favorite YouTube videos." The problematic part of the DMCA is Section 1201, he reminded the crowd, "which makes it a crime to give people tools that they could use to bypass DRM." But that law was just the beginning: the US Trade Representative has been "patient zero," spreading the problem around the world by persuading other countries to enact their own equivalent laws. The worst example was the New Zealand law's Section 92A, which sparked protests in the streets. The backlash initially derailed the bill, he said, but entertainment industry lobbyists forced it through by reintroducing it as a rider on the disaster-relief bill passed after the 2011 Christchurch earthquake.

While such laws spread around the globe, DRM was also making its way into more and more devices. The Lexmark printer-cartridge case is a well-known example, as was the case of Skylink garage-door openers. In both cases, a company used poor, easily broken encryption software to attempt to block interoperability with third-party products, then sued rival companies who broke the encryption. In both instances, the courts sided with the defendants, noting that the DMCA only protects copyrighted works (rather than, say, trade secrets), which meant that the only DMCA-protected work in the Lexmark printer cartridge or Skylink garage-door opener was the DRM software itself.

But those cases were years ago, Doctorow noted; today, more and more devices do include significant amounts of software inside, from WiFi light bulbs to smart appliances, even to smartphone-enabled rectal thermometers—"yes, they now want to put DRM up our asses," he told the crowd to a peal of laughter. The sole reason the makers of these products are employing DRM is to stifle competition, he said; it has nothing to do with "piracy" and never has. Furthermore, DRM has never been a selling point; "if there were two Netflixes for the same price," he said, "and the only difference was that one had a 'save' button, no one would ever sign up for the other one."

Follow the money

The clear conclusion is that people are either oblivious to the DRM around them or they just do not care. Yes, he conceded, there will always be "a few supernerds" with the skills to bypass DRM themselves, but without real reform, DRM will continue to prop up anti-competitive behavior in the global economy.

Companies make money with anti-competition in three ways, he said. First, they double-dip on sales, as when they require people who have bought DVDs legally to pay again to put the same video on their phone. Second, they control parts and repairs. There are cheap diagnostic scanners that can read car "check engine" codes, but only for individuals; mechanics "operating a business with an address you can sue them at" have to buy expensive scan tools from carmakers, who require them to also sign contracts to purchase all replacement parts directly from the company. Finally, they make money by making promises to other businesses. For instance, cell carriers give away iPhones to customers, but only because Apple has promised to prevent those customers from ever installing a tethering app—by locking down the OS with DRM.

So, every day, "DRM costs you and me and everybody we love money," Doctorow said, "but that's not why I worry and that's not why I've returned to the EFF," Doctorow said. What worries him is how DRM prevents the patching of security vulnerabilities. When we can't examine our devices, we are stuck with ancient software filled with unfixable bugs.

He shared several "horror stories" about DRM. The Jeep remote exploit Charlie Miller and Chris Valasek published in 2015 was demonstrated on that car because that model's software did not employ DRM and the authors could thus avoid a felony prosecution. Subsequently, other automotive-security researchers have said similar flaws affect most other cars, but their lawyers have advised them not to disclose the vulnerabilities.

Jay Radcliffe (who is diabetic), refuses to use an insulin pump "thus taking years off his life" because of the security vulnerabilities he has seen in the devices' software, but which he cannot disclose because they are "protected" by DRM. In Ukraine, people who took their mobile phones near the site of anti-government protests later received text messages saying that they had been recorded as participating in an illegal action and warning them against doing so again. The unique identifiers baked into each phone are protected by DRM.

There were plenty of other examples, from John Deere tractors to voting machines to criminals capturing wireless webcam video and blackmailing the owners by threatening to publish the camera footage online. DRM makes it illegal to disclose security vulnerabilities in devices, and the Internet of Things makes that problem ubiquitous. That, Doctorow said, is why he decided to return to the EFF to work on the Apollo 1201 project.

Apollo

The goal of Apollo 1201 is to eradicate DRM in ten years' time by rewriting the laws. If you work on any sort of anti-circumvention project, Doctorow said, the EFF wants to talk with you. The point of the conversation is two-fold. First, the EFF can provide advice on how to structure one's project and how to discuss it publicly (although he made a point to say this was not of the formal "legal advice" variety). Second, the EFF wants to be prepared for when such projects inevitably result in lawsuits; it plans to fight a number of such cases and to take the fight all the way to the Supreme Court.

Since code is ultimately a form of First-Amendment–protected speech, the EFF is confident it can eventually defeat Section 1201 on Constitutional grounds. That process will likely take close to a decade. Fortunately, "this is a target-rich environment," he said, so the EFF believes it will have no trouble finding solid test cases and well-prepared defendants to work with.

In the meantime, though, a lot can change on the ground. As soon as the DRM threat for a particular product class begins to look uncertain, he said, companies will begin to attack the profit margins of the DRM purveyor. That will bring the fight to a second front (markets). And the courts, he said, deeply want the law to be relevant: if it is obvious that successful businesses and millions of people regard DRM as an obsolescence, they will rule against DRM. That principle was a large part of why the court upheld home recording in the 1984 Betamax case: millions of households already used VCRs to tape television.

He also challenged the audience to take the fight to the "norms" front, to talk about DRM wherever they can. "We're at peak indifference now. Every week, something bad [like the horror stories he related] will happen. When the people you know ask you how this happened, tell them." Finally, he asked the audience to do what they can to support the work of fighting DRM. "You probably give money to one of these companies every month," he said. "I just ask you to tie it, to match what you give these companies with something you give to organizations fighting for your freedom."

After the keynote, Doctorow stayed to discuss the project further and to answer questions. Among other matters, he said that the EFF may have already identified what project will be its first Apollo 1201 test case, and that the defendant in that case has been braced for such a fight for many years—even before the EFF announced the project.

He also noted that there was a chance that a case the EFF takes might result in only a narrow ruling, rather than cutting out the heart of Section 1201. But that is still a victory, he said, and narrow rulings can still shift the economic factors in a major way. As in the "dancing baby" case, where the court ruled that copyright holders must consider fair use before issuing any DMCA takedown notices, or else be held responsible for damages. The ruling turns the mass issuance of takedown notices into a financially risky proposition for entertainment publishers, a fact that defense attorneys are beginning to notice. He also encouraged open-source developers to join the fray and help disrupt the DRM-protected businesses. "We want people to see that there's money in them there circumvention devices."

Comments (7 posted)

Trademarks for open-source projects

SCALE 14x featured a dedicated legal track requiring separate registration. While much of the content was aimed at lawyers working in open-source software or at companies investigating the legal aspects of open-source software for the first time, there were also sessions of interest to software developers. One such session was Pamela Chestek's Trademarks and FOSS: Entirely the Same and Entirely Different, which looked at how trademarks impact developers within an open-source project as well as those who are downstream users of the code.

Many in the community recognize Chestek either from her years at Red Hat or, more recently, for acting on behalf of the GNOME Foundation when it faced a trademark battle with the web service Groupon. While trademark law is well understood by many in the legal profession, she said, open-source projects have tended to ignore it—at least in comparison to their understanding of copyright and patent law.

Chestek opened up the session with a brief look at how trademark law functions. By definition, a trademark is a "symbolic representation of the sum of information about a product or service"—or what marketing calls "the brand." A key concept is that trademark traditionally points to a "unique single source" for a brand, but any particular usage of a trademark can signal a variety of different relationships.

For instance, the Apple logo on a MacBook designates Apple as the party that the laptop "comes from," even though multiple subcontractors actually built it. A software vendor that offers certification may allow independent contractors to advertise with its certification's trademarks, even though they are not employees. That usage designates more a "seal of approval" for the contractors. Trademarks can also be used in advertising relationships, such as "Volvo Fashion Week." That usage makes it clear that Volvo is sponsoring the event, Chestek said, and no one is likely to misunderstand and think that the carmaker is also producing clothing. The absence of misunderstanding is critical, she said: the only thing that the law prohibits is the usage of someone else's trademark in a way that causes confusion about the relationship being signaled.

Trademarks from a project's perspective

For open-source software, though, these principles create considerable tension. First, trademarks are often lumped together with copyrights and patents in the broad "intellectual property" pool, which is generally mistrusted by open-source projects. Second, trademark law's "unique single source" concept does not map well to open-source projects' distributed, ad-hoc membership and open participation model. Finally, trademark law in most jurisdictions comes from the manufacturing era of a century ago, and does not mesh easily with how open-source software is produced.

On the intellectual-property front, Chestek argued that, while almost all open-source developers find software patents "all bad" and copyrights to be a mixed bag (after all, copyright is what allows open-source licenses to function), trademarks should be seen as the "all good" piece of the puzzle. That is because most projects' primary or only trademark is the project name, and looking after the name is how the project protects its reputation.

Trademarks fit well with the "fandom" that many projects rely on to build a community and to turn users into contributors. They also enable projects to offer assurances that users know what they are getting from the software. A bad actor could insert malware into open-source code that it redistributes; while copyright would offer no recourse (as long as the license requirements are met), trademark law would let the project step in and shut down the malware redistributor. Mozilla has had to take such steps more than once in the past.

Regarding the "unique single source" doctrine of trademark law, some lawyers think that open-source development's "anyone can submit a patch" nature undermines trademarks, but Chestek disagrees. Yes, anyone can modify and redistribute code, she said, but it is not "the Wild, Wild West." In reality, projects operate in a systematic fashion. There is a canonical source for releases and there is an organizational structure. Furthermore, she said, many of the same issues (such as who in the organization determines what is allowable trademark usage) already arise in other endeavors—particularly not-for-profit ones. From volunteer work to church raffles to bands that split up and disagree about which member gets to use the old band name, the same issues that open-source projects encounter are regularly seen elsewhere.

Current trademark law in the US was rewritten in 1946, and the previous update was in 1908. In both eras, Chestek said, the assumption was that a product was a physical, manufactured good. But open-source software is built and distributed differently, which can be problematic. For instance, she noted that it is common practice for one project to intentionally choose a name that is similar to another project's, such as NHibernate, which is a .NET port of the Java-based Hibernate framework. That name communicates to the user about compatibility. Although common practice, she said, it is a strategy that projects will likely have to abandon if they grow—much as the Jenkins project had to change its name when it forked from Hudson. The main Hudson developers started the fork, but were told by Oracle that they could not use "Hudson" for its name.

Above all else, Chestek urged projects to register their trademarks—at the very least, in a major jurisdiction like the US or the EU, but wherever possible. There are two benefits. First, the registration forces project members to take a serious look at their structure and have the conversation about who owns what; that conversation can be more valuable than the legal filing it eventually produces. Second, registering a trademark is the key way to get the mark on the radar of anyone doing a trademark-clearance search. Most companies do want to create their own brand and identity in good faith, she said, but they generally do not know where to look for open-source software project names. If the names are registered as trademarks, however, they can be found.

Trademarks from a downstream perspective

Chestek then addressed several frequently asked questions about trademarks that arise for the users of open-source software, including downstream projects. The first question was whether there really is a "duty to enforce" a trademark. Such a duty is often claimed, she said: many cease-and-desist letters assert that the trademark holder has to enforce a trademark or lose it. But "there is actually no such thing," she said, "those words do not appear in the Trademark Act."

Rather, she explained, there is a continuum of trademark usage that could be seen as confusing, and a trademark holder has the right to enforce their trademark on a confusing usage. But only the bottom end of that continuum involves anything like "losing" a trademark, and that situation is when a court decides that a trademark has become so widely used that it has turned into a generic term for a product category. It is a rare occurrence, but not impossible: Chestek speculated that the "Linux" trademark runs the risk of becoming a generic term for a category of software. She wondered how many projects actually bother to apply for authorization from the Linux Mark Institute.

The second question was whether a trademark covers exact copies distributed downstream (that is, whether or not the trademark would have an infringement case if the downstream product used the trademark in, say, advertising). Unfortunately, the answer seems to vary depending on the jurisdiction (in the US, the trademark is likely extended to the copy, but it is likely not in the EU).

Whether a project's trademarks extend to downstream forks is a more interesting question. Chestek believes that the upstream trademark is not transferred to forks, so forks need to remove any usage of the mark. But even that has limits; in particular, she believes a project cannot demand that downstream forks remove its trademarks if doing so would functionally alter the program. The example she gave was a project using its name in function names, class names, and commands. If the command-line tools are FooBuild or FooRun, requiring users to change the names would impede script compatibility, and impair usage.

Nevertheless, she cautioned that there is no US case law on this topic, and others may disagree. For projects concerned about that uncertainty, she said they could always write their own trademark guidelines and offer to grant trademark licenses to downstream users; that would clarify the matter for users.

Chestek closed by recommending that projects explore writing a trademark policy, looking to the Model Trademark Guidelines and FOSSmarks sites for help. Trademarks are underrated and underfunded in open-source software, she said, but an open-source project's name is often its heart and soul, so it needs protection.

Comments (5 posted)

The Linux Foundation changes its bylaws

The Linux Foundation's board of directors is not usually a hotbed of controversy; for the most part it does its work in the background, quietly going about the business of directing the non-profit organization. In mid-January that all changed. The bylaws that governed how some at-large board seats were allocated were changed, which caused quite an uproar within the Linux world. While there is speculation about the motive for the change—as well as an official statement of sorts—it certainly seems like the whole thing could have been handled a lot better.

Until the change, which was made on January 14, two of the Linux Foundation (LF) board's "at-large" directors were elected by the individual (as opposed to corporate) members of the LF. Those seats were filled by Bdale Garbee and Larry Augustin (and still are, the board re-appointed them to the seats after the bylaw change). A third community representative comes from the Technical Advisory Board (TAB), which is comprised of kernel developers who are elected at the annual Kernel Summit. The TAB chair has traditionally been added to the LF board and that is the case now, with Grant Likely serving as the TAB representative to the board.

Out of sixteen members, the LF board has three that are meant to represent the community, while the rest are made up of representatives of the companies that have joined the foundation. As pointed out by Matthew Garrett, the LF board changed its bylaws, quietly, to remove the possibility of directly electing the two at-large seats. In addition, the $99/year "individual member" option was quietly switched to an "individual supporter"—with all mention of running for and electing seats on the board removed.

Garrett's speculation was that the move was precipitated by Karen Sandler's candidacy for the LF board. Sandler, who is the executive director of the Software Freedom Conservancy (SFC) actually announced that she was running back in September. The changes to the LF individual member/supporter program and to the bylaws all took place in that time frame, which Garrett said "may be coincidental", but it didn't really look that way to him. To his eye, it seemed that the GPL-enforcement suit that SFC is funding against LF-member VMware made the LF "willing to throw out any semblance of community representation just to ensure that there was no risk of someone in favour of GPL enforcement ending up on their board".

That posting set off quite a firestorm on Garrett's blog, here at LWN, and elsewhere. As with many controversies in our community, the comments ranged from sober analysis to intemperate rants to outright trolling. On reddit, Greg Kroah-Hartman (who works for the Linux Foundation, but was not commenting on its behalf) replied to the uproar at some length. He noted that electing board seats from the general membership is not common for non-profits. Furthermore:

The speculation about two HP board seats may be part of the equation, but the fact that the board re-appointed Garbee is then a bit puzzling. Garbee is far more than just his HP affiliation, however, having been a part of the Debian project for many years (including as Debian project leader and chair of its technical committee along the way). But there is also the question of how these actions could be taken without any notice to the community, before or after the changes were made. In the reddit comment exchange with Garrett, Kroah-Hartman said that is simply the way boards normally operate:

But Garrett disagreed:

LF executive director (and board member) Jim Zemlin weighed in with a blog post that echoed some of what Kroah-Hartman said:

Zemlin also decried some of the comments about Sandler that were cropping up in various online forums. While many of those comments are certainly deplorable (as well as inaccurate and irrelevant), Zemlin focused mainly on that and did not directly address much of what Garrett (and others) have alleged.

Further inquiries about the vote and the reasons behind it have largely been met with silence. When asked in email, Likely deferred any questions (including how he voted) to Zemlin, who has not responded to an email inquiry. Also in email, Garbee said that he voted against the proposal to eliminate the elections; so far, Augustin has not responded.

The LF is a non-profit, but not a charity. It is, instead, a US 501(c)(6) corporation that is organized as a consortium for the benefit of its members. For the most part, those are Linux-oriented companies. The bylaws state: "The purposes of this corporation include promoting, protecting, and standardizing Linux and open source software." Those are all laudable goals, of course, but Linux is far larger than simply the companies that have chosen to join the LF.

One could imagine that the board members (and the companies they represent) were a little nervous about some kind of activist (whether it be Sandler or someone else) getting elected to the board. GPL-enforcement activism may well be part of that concern, but there could be other factors at play here too.

There seems to be something of a veil of secrecy around the board's activities; there appear to be no published minutes from the meetings, for example. That secrecy might not be honored by some potential board members (though Sandler would not seem likely to be one of those). It is not clear, exactly, what the board might be doing that requires such secrecy (especially with regard to open source), but that is traditionally how boards operate. Being able to ensure that it can do its work quietly in the background may be one of the prime motivations for this change.

Given the level of secrecy, the community representation does not really amount to all that much in some ways. One hopes and believes that those representatives are voting and contributing for the benefit of the community, but we don't have any direct way of knowing that. We do know that the LF has done lots of good things for Linux from funding developers and their travel to the Core Infrastructure Initiative and running kernel.org—and plenty more. The board has undoubtedly had a good deal of influence on that. One can quibble with some of its decisions, projects, and programs, but the LF has also been a strong, capable advocate for the advancement of Linux over the years.

It should also be noted that $99 per vote to elect the at-large board members is hardly the right mechanism to get community members onto the board. That kind of system can be too easily gamed, for one thing. But it did at least give the appearance of a way for those outside of the member companies to influence the direction of the LF. On the other hand, having the board self-select those community representatives, as it appears it will be now, is not a particularly good option either.

In the end, though, the LF is set up by and for its members and they can certainly do whatever they want in terms of seats on the board. In some sense, it was the illusion that the seats could be elected "by the community" that was lost, thus the outcry. In the end, at-large seats were always subject to the rest of the board's approval, but removing a duly elected board seat would have been even more unpopular than this move has been.

Thinking that these changes would be able to "fly under the radar", however, seems like a serious miscalculation. Many readers may not have been LF members, thus were not truly affected by the change, but still felt disenfranchised by it. The appearance that the board is "circling the wagons" against community participation is probably not accurate, exactly, but is still strongly felt in many quarters.

One cannot go long at an LF event without hearing the word "collaborate"; this would have seemed like an opportunity to do just that. Perhaps this proposal came out of the blue and was quickly approved, but that does not seem all that likely. Before making these kinds of changes, explaining the problem and looking for solutions with the community would seem a more sensible approach. The logistics would be tricky, perhaps, and there might still be some loud voices expressing displeasure, but collaboration is not necessarily easy. Perhaps the board will look at better ways of somehow enfranchising "the community" to represent its interests within the LF down the road.

Comments (33 posted)

Automotive security and safety

The security of the software that runs in vehicles is a hot-button issue at the moment. At SCALE 14x, automotive-software engineer Alison Chaiken provided an insider look at the issue, including how software-development issues interact with regulatory agencies—and not always for the better.

Chaiken started off by explaining that she has been working on automotive software for the past several years (most recently at Mentor Graphics), but that the security landscape for automotive is so fast-changing that it is almost all she can do to keep up with the news. That is because the regulators (at the state and federal level) are busy trying to catch up with the security problems that the car manufacturers have wrought—while also making an effort to get ahead of the problem for autonomous vehicles.

Up until now, those regulators have had a decidedly mixed impact on automotive-software security. Chaiken cited the US National Highway Traffic Safety Administration (NHTSA) requirement that in-vehicle infotainment (IVI) head units show a rear-camera view, complete with lane overlays, two seconds after boot. This is a remarkably difficult metric to meet, and was rather arbitrary. Had the rule been three seconds instead of two, automotive-software makers could have saved countless hours and costs that could have been spent on safety and security issues instead.

The bad news

Automotive security has three main problem areas, she said: bad legacy designs, an unclear privacy situation, and the chilling effects of "digital rights management" (DRM). The insecure software found in many older cars is rife with security vulnerabilities, but it is a mistake to think that the industry's shift toward Linux is an automatic fix. In 2015, Charlie Miller and Chris Valasek found "five-ish" exploits in Jeep Cherokees. The most appalling was that anyone with a Sprint phone could get in range of a cell tower, scan for IP addresses in the range used by Jeep, and find D-Bus listening for connections on port 6667.

To make matters worse, Jeep did not build in an over-the-air update system, so the only way these vehicles could be patched is by downloading a new firmware image onto a USB stick and plugging it into the car. Hopefully into one's own car, although Chaiken noted that the company web site asked users for no authentication or even an assertion of ownership before allowing them to download a firmware image. The images on the site, she said, were virtually identical to the ones reverse engineered by Miller and Valasek, and the cars do not perform authentication, either. Nevertheless, at least open-source projects like GENIVI and Automotive Grade Linux allow people to participate and allow the security-conscious to read the source code; the same cannot be said of most legacy OSes running in cars, such as QNX.

"On the other hand, Linus [Torvalds] can't solve everything," she said, particularly where privacy is concerned. Many automotive systems seem to be designed with a "one user per device" model in mind that was copied over wholesale from mobile phones, but surely does not apply. What happens when you pair your phone with a rental car, she asked, or leave your car overnight with a mechanic? No one would leave their smartphone or laptop overnight with a repair shop, but automotive computer systems are poised to collect just as much personal information as either of those devices. Chaiken has asked carmakers how they plan to reset or blank out the personal data they collect, and received vacant stares in reply.

The security and privacy concerns are important enough in their own right, but they get more complex when government regulators get involved. She cited two examples. First, NHTSA rules in 2012 required telematics "black boxes" to record 14 specific vehicle data streams that could be used to help determine the cause of an accident. But the regulation failed to state that the data could only be used for accident service, and drivers found themselves being monitored around the clock and denied warranty coverage if a sensor reading suggested that they had, for example, exceeded a "safe" engine speed. The Electronic Frontier Foundation (EFF) filed a complaint, although it has yet to succeed at having the rules amended or replaced.

The second example is the still-ongoing exploration of driver drowsiness detection. If would certainly save lives if cars would trigger alarms when a drowsy driver nodded off, but making such a feature possible likely requires capturing a constant video stream—which has serious privacy risks.

It is easy to dismiss such privacy concerns now, Chaiken said, but that is only because of the old adage that "the best way to avoid being attacked is to be poor and boring." And right now, there are few real-world car exploits being seen because cars do not yet store payment information. Thieves have always stolen radios out of cars; once those dash units also include personal information and credit card numbers, she said, you can expect the thieves to be right behind. She noted that Visa recently announced a "connected car" initiative, and urged developers to resist the temptation to store payment data in vehicles.

The good news

Despite all the doom and gloom, Chaiken also shared what she regards as promising news on several fronts. The first is that NHTSA is preparing its rules on vehicle-to-vehicle (V2V) networking, and is using public-key encryption (PKE) to secure it. PKE will make it drastically harder for an attacker to spoof an emergency vehicle, but it has beneficial side effects, too. For example, the scheme uses short-lived keys, which protects against replays, but also makes it hard to track a single vehicle over a long period of time.

Another welcome change is the increased use of virtualization. Future car systems will not boot directly into Linux or QNX, but into a hypervisor. That will enable better separation of functionality, making it harder, for instance, for an attacker to get to the engine-control unit via the IVI unit. And automakers have already begun implementing watchdog timers to reboot stalled virtual machines, which will also make attacks more difficult.

There has also been a shift away from outdated network buses like Controller Area Network (CAN) to more robust alternatives like Ethernet Audio Video Bridging (AVB). And although Chaiken did not go into depth on the problems of DRM in the "bad news" section of the talk (referring the audience, instead, to Cory Doctorow's thorough keynote on the topic), she cited the automotive exemption to the Digital Millennium Copyright Act's DRM provision as an important win by the EFF.

Finally, she said, it is important to remember that big carmakers are no longer the sole creators of vehicles. There are several new start-ups, most notably OSVehicle (OSV) and Local Motors that are working on making a home-made, "white box" car. OSV, she said, wants to be the Gateway Computer of the automotive market. Whoever succeeds at that task, consumers will win.

In closing, Chaiken cautioned that the push to make cars more high tech can all too easily make them less safe. The regulations are still being written—even today, the California Department of Transportation is debating autonomous vehicle regulations. "If we keep getting rules about boot speed instead of about security," she said, "then we're not heading for a good place." Nevertheless, there is now a lot of open-source code involved in the process, so the security lessons understood by the Linux community all apply to this new problem space.

Comments (19 posted)

Security quote of the week

— Lauren Weinstein

Comments (1 posted)

bind: denial of service

Package(s):	bind	CVE #(s):	CVE-2015-8705
Created:	January 21, 2016	Updated:	January 27, 2016
Description:	From the Arch Linux advisory: CVE-2015-8705 (denial of service): In versions of BIND 9.10, errors can occur when OPT pseudo-RR data or ECS options are formatted to text. In 9.10.3 through 9.10.3-P2, the issue may result in a REQUIRE assertion failure in buffer.c resulting in application exit. This issue can affect both authoritative and recursive servers if they are performing debug logging. It may also crash related tools which use the same code, such as dig or delv.
Alerts:	Gentoo 201610-07 bind 2016-10-11 Fedora FEDORA-2016-1ab53bf440 bind 2016-02-02 Fedora FEDORA-2016-f3517b9c4c bind 2016-01-24 Mageia MGASA-2016-0030 bind 2016-01-20 Arch Linux ASA-201601-21 bind 2016-01-21 Slackware SSA:2016-054-01 bind 2016-02-23

Comments (none posted)

cgit: three vulnerabilities

Package(s):	cgit	CVE #(s):	CVE-2016-1899 CVE-2016-1900 CVE-2016-1901
Created:	January 22, 2016	Updated:	April 8, 2016
Description:	From the openSUSE advisory: - CVE-2016-1899: Reflected Cross Site Scripting and Header Injection in Mimetype Query String - CVE-2016-1900: Stored Cross Site Scripting and Header Injection in Filename Parameter - CVE-2016-1901: Integer Overflow resulting in Buffer Overflow
Alerts:	Fedora FEDORA-2016-e5a5fb196f cgit 2016-01-26 Fedora FEDORA-2016-215b507409 cgit 2016-01-26 openSUSE openSUSE-SU-2016:0218-1 cgit 2016-01-24 openSUSE openSUSE-SU-2016:0196-1 cgit 2016-01-22 Debian DSA-3545-1 cgit 2016-04-07 Mageia MGASA-2016-0047 cgit 2016-02-05

Comments (none posted)

chromium: multiple vulnerabilities

Package(s):	chromium	CVE #(s):	CVE-2016-1612 CVE-2016-1613 CVE-2016-1614 CVE-2016-1615 CVE-2016-1616 CVE-2016-1617 CVE-2016-1618 CVE-2016-1619 CVE-2016-1620
Created:	January 26, 2016	Updated:	January 28, 2016
Description:	From the CVE entries: The LoadIC::UpdateCaches function in ic/ic.cc in Google V8, as used in Google Chrome before 48.0.2564.82, does not ensure receiver compatibility before performing a cast of an unspecified variable, which allows remote attackers to cause a denial of service or possibly have unknown other impact via crafted JavaScript code. (CVE-2016-1612) Multiple use-after-free vulnerabilities in the formfiller implementation in PDFium, as used in Google Chrome before 48.0.2564.82, allow remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted PDF document, related to improper tracking of the destruction of (1) IPWL_FocusHandler and (2) IPWL_Provider objects. (CVE-2016-1613) The UnacceleratedImageBufferSurface class in WebKit/Source/platform/graphics/UnacceleratedImageBufferSurface.cpp in Blink, as used in Google Chrome before 48.0.2564.82, mishandles the initialization mode, which allows remote attackers to obtain sensitive information from process memory via a crafted web site. (CVE-2016-1614) The Omnibox implementation in Google Chrome before 48.0.2564.82 allows remote attackers to spoof a document's origin via unspecified vectors. (CVE-2016-1615) The CustomButton::AcceleratorPressed function in ui/views/controls/button/custom_button.cc in Google Chrome before 48.0.2564.82 allows remote attackers to spoof URLs via vectors involving an unfocused custom button. (CVE-2016-1616) The CSPSource::schemeMatches function in WebKit/Source/core/frame/csp/CSPSource.cpp in the Content Security Policy (CSP) implementation in Blink, as used in Google Chrome before 48.0.2564.82, does not apply http policies to https URLs and does not apply ws policies to wss URLs, which makes it easier for remote attackers to determine whether a specific HSTS web site has been visited by reading a CSP report. (CVE-2016-1617) Blink, as used in Google Chrome before 48.0.2564.82, does not ensure that a proper cryptographicallyRandomValues random number generator is used, which makes it easier for remote attackers to defeat cryptographic protection mechanisms via unspecified vectors. (CVE-2016-1618) Multiple integer overflows in the (1) sycc422_to_rgb and (2) sycc444_to_rgb functions in fxcodec/codec/fx_codec_jpx_opj.cpp in PDFium, as used in Google Chrome before 48.0.2564.82, allow remote attackers to cause a denial of service (out-of-bounds read) or possibly have unspecified other impact via a crafted PDF document. (CVE-2016-1619) Multiple unspecified vulnerabilities in Google Chrome before 48.0.2564.82 allow attackers to cause a denial of service or possibly have other impact via unknown vectors. (CVE-2016-1620)
Alerts:	Mageia MGASA-2016-0274 chromium-browser-stable 2016-08-03 Mageia MGASA-2016-0042 chromium-browser-stable 2016-01-29 Ubuntu USN-2877-1 oxide-qt 2016-01-27 openSUSE openSUSE-SU-2016:0271-1 Chromium 2016-01-27 openSUSE openSUSE-SU-2016:0250-1 Chromium 2016-01-26 openSUSE openSUSE-SU-2016:0249-1 Chromium 2016-01-26 Debian DSA-3456-1 chromium-browser 2016-01-27 Red Hat RHSA-2016:0072-01 chromium-browser 2016-01-27 Arch Linux ASA-201601-28 chromium 2016-01-25 Gentoo 201603-09 chromium 2016-03-12

Comments (none posted)

chrony: packet modification

Package(s):	chrony	CVE #(s):	CVE-2016-1567
Created:	January 25, 2016	Updated:	December 14, 2016
Description:	From the Red Hat bugzilla: The following flaw was found in chrony: Symmetric key encryption requires a single trusted key to be specified for each server configuration. A key specified only for one server should only work to authenticate that server, other trusted keys should be refused. However, when symmetric key authentication is verified, there is no check that the key used is the key specified for the address, any trusted key can be used as long as the keyid references another key the systems share and that key is used to compute the MAC. An authenticated client (A) could use this flaw to modify a packet sent between a server (B) and a client (C) using a key that is different from the one known to the client (A).
Alerts:	Fedora FEDORA-2016-6f783d1768 chrony 2016-02-02 Mageia MGASA-2016-0038 chrony 2016-01-29 Fedora FEDORA-2016-6a0b0ab775 chrony 2016-01-24 Debian-LTS DLA-742-1 chrony 2016-12-13 Debian-LTS DLA-414-1 chrony 2016-02-12

Comments (none posted)

curl: authentication bypass

Package(s):	curl	CVE #(s):	CVE-2016-0755
Created:	January 27, 2016	Updated:	February 17, 2016
Description:	From the Debian advisory: Isaac Boukris discovered that cURL, an URL transfer library, reused NTLM-authenticated proxy connections without properly making sure that the connection was authenticated with the same credentials as set for the new transfer. This could lead to HTTP requests being sent over the connection authenticated as a different user.
Alerts:	Gentoo 201701-47 curl 2017-01-19 Fedora FEDORA-2016-3fa315a5dd curl 2016-02-02 Arch Linux ASA-201602-4 lib32-curl 2016-02-02 Arch Linux ASA-201602-3 curl 2016-02-02 Fedora FEDORA-2016-57bebab3b6 curl 2016-01-30 Ubuntu USN-2882-1 curl 2016-01-27 Debian DSA-3455-1 curl 2016-01-27 SUSE SUSE-SU-2016:0778-1 sles11sp4-docker-image 2016-03-15 Fedora FEDORA-2016-5a141de5d9 mingw-curl 2016-02-17 Fedora FEDORA-2016-55137a3adb mingw-curl 2016-02-17 Slackware SSA:2016-039-01 curl 2016-02-08 openSUSE openSUSE-SU-2016:0376-1 curl 2016-02-08 openSUSE openSUSE-SU-2016:0373-1 curl 2016-02-07 openSUSE openSUSE-SU-2016:0360-1 curl 2016-02-07 Mageia MGASA-2016-0050 curl 2016-02-05

Comments (none posted)

foomatic-filters: buffer overflows

Package(s):	foomatic-filters	CVE #(s):
Created:	January 25, 2016	Updated:	January 27, 2016
Description:	From the Debian LTS advisory: cups-filters contains multiple buffer overflows caused by lack of size checks when copying from environment variables to local buffers (strcpy) as well on string concatenation operations (strcat).
Alerts:	Debian-LTS DLA-399-1 foomatic-filters 2016-01-23

Comments (none posted)

fuse: privilege escalation

Package(s):	fuse	CVE #(s):	CVE-2016-1233
Created:	January 22, 2016	Updated:	January 27, 2016
Description:	From the Debian advisory: Jann Horn discovered a vulnerability in the fuse (Filesystem in Userspace) package in Debian. The fuse package ships an udev rules adjusting permissions on the related /dev/cuse character device, making it world writable. This permits a local, unprivileged attacker to create an arbitrarily-named character device in /dev and modify the memory of any process that opens it and performs an ioctl on it. This in turn might allow a local, unprivileged attacker to escalate to root privileges.
Alerts:	Debian DSA-3451-1 fuse 2016-01-21

Comments (none posted)

imlib2: denial of service

Package(s):	imlib2	CVE #(s):	CVE-2014-9762 CVE-2014-9763 CVE-2014-9764
Created:	January 25, 2016	Updated:	February 10, 2016
Description:	From the Debian LTS advisory: CVE-2014-9762: GIF loader: Fix segv on images without colormap CVE-2014-9763: Prevent division-by-zero crashes CVE-2014-9764: Fix segfault when opening input/queue/id:000007,src:000000,op:flip1,pos:5
Alerts:	Ubuntu USN-3075-1 imlib2 2016-09-08 Fedora FEDORA-2016-b62d19661f imlib2 2016-01-30 Debian-LTS DLA-401-1 imlib2 2016-01-24 openSUSE openSUSE-SU-2016:1330-1 imlib2 2016-05-18 Debian DSA-3537-1 imlib2 2016-03-31 Fedora FEDORA-2016-3c0b37e056 imlib2 2016-02-10 Mageia MGASA-2016-0049 imlib2 2016-02-05 Gentoo 201611-12 imlib2 2016-11-21

Comments (none posted)

jasper: denial of service

Package(s):	jasper	CVE #(s):	CVE-2016-1867
Created:	January 25, 2016	Updated:	February 10, 2016
Description:	From the CVE entry: The jpc_pi_nextcprl function in JasPer 1.900.1 allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted JPEG 2000 image.
Alerts:	openSUSE openSUSE-SU-2016:2737-1 jasper 2016-11-05 Fedora FEDORA-2016-bbecf64af4 jasper 2016-09-21 Fedora FEDORA-2016-7776983633 jasper 2016-08-15 Debian DSA-3785-1 jasper 2017-02-09 openSUSE openSUSE-SU-2016:0217-1 jasper 2016-01-24 openSUSE openSUSE-SU-2016:0211-1 jasper 2016-01-24 Mageia MGASA-2016-0059 jasper 2016-02-09 openSUSE openSUSE-SU-2016:2833-1 jasper 2016-11-17

Comments (none posted)

java: weak key generation

Package(s):	java-1.8.0-openjdk	CVE #(s):	CVE-2016-0475
Created:	January 21, 2016	Updated:	January 27, 2016
Description:	From the Red Hat advisory: It was discovered that the password-based encryption (PBE) implementation in the Libraries component in OpenJDK used an incorrect key length. This could, in certain cases, lead to generation of keys that were weaker than expected. (CVE-2016-0475)
Alerts:	Gentoo 201610-08 oracle-jdk-bin 2016-10-15 Red Hat RHSA-2016:0098-01 java-1.8.0-ibm 2016-02-02 SUSE SUSE-SU-2016:0256-1 java-1_8_0-openjdk 2016-01-27 Scientific Linux SLSA-2016:0049-1 java-1.8.0-openjdk 2016-01-21 CentOS CESA-2016:0050 java-1.8.0-openjdk 2016-01-21 CentOS CESA-2016:0049 java-1.8.0-openjdk 2016-01-21 Scientific Linux SLSA-2016:0050-1 java-1.8.0-openjdk 2016-01-20 Red Hat RHSA-2016:0055-01 java-1.8.0-oracle 2016-01-21 Red Hat RHSA-2016:0050-01 java-1.8.0-openjdk 2016-01-20 Red Hat RHSA-2016:0049-01 java-1.8.0-openjdk 2016-01-20 SUSE SUSE-SU-2016:0390-1 java-1_8_0-ibm 2016-02-09 Mageia MGASA-2016-0048 java-1.8.0-openjdk/copy-jdk-configs/lua-lunit/lua-posix 2016-02-05

Comments (none posted)

java: multiple vulnerabilities

Package(s):	java-1.6.0-sun	CVE #(s):	CVE-2016-0402 CVE-2016-0448 CVE-2016-0466 CVE-2016-0483 CVE-2016-0494
Created:	January 21, 2016	Updated:	February 2, 2016
Description:	From the Red Hat advisory: CVE-2016-0494 ICU: integer signedness issue in IndicRearrangementProcessor (OpenJDK 2D, 8140543) CVE-2016-0402 OpenJDK: URL deserialization inconsistencies (Networking, 8059054) CVE-2016-0448 OpenJDK: logging of RMI connection secrets (JMX, 8130710) CVE-2016-0466 OpenJDK: insufficient enforcement of totalEntitySizeLimit (JAXP, 8133962) CVE-2016-0483 OpenJDK: incorrect boundary check in JPEG decoder (AWT, 8139017)
Alerts:	Gentoo 201610-08 oracle-jdk-bin 2016-10-15 Debian-LTS DLA-545-1 icu 2016-07-07 Red Hat RHSA-2016:0098-01 java-1.8.0-ibm 2016-02-02 Red Hat RHSA-2016:0099-01 java-1.7.1-ibm 2016-02-02 Red Hat RHSA-2016:0100-01 java-1.7.0-ibm 2016-02-02 Red Hat RHSA-2016:0101-01 java-1.6.0-ibm 2016-02-02 openSUSE openSUSE-SU-2016:0279-1 java-1_7_0-openjdk 2016-01-28 SUSE SUSE-SU-2016:0269-1 java-1_7_0-openjdk 2016-01-27 SUSE SUSE-SU-2016:0265-1 java-1_7_0-openjdk 2016-01-27 openSUSE openSUSE-SU-2016:0272-1 Java7 2016-01-28 openSUSE openSUSE-SU-2016:0270-1 java-1_8_0-openjdk 2016-01-27 openSUSE openSUSE-SU-2016:0263-1 java-1_8_0-openjdk 2016-01-27 openSUSE openSUSE-SU-2016:0268-1 java-1_7_0-openjdk 2016-01-27 Debian DSA-3458-1 openjdk-7 2016-01-27 SUSE SUSE-SU-2016:0256-1 java-1_8_0-openjdk 2016-01-27 Scientific Linux SLSA-2016:0067-1 java-1.6.0-openjdk 2016-01-26 Oracle ELSA-2016-0067 java-1.6.0-openjdk 2016-01-26 Oracle ELSA-2016-0067 java-1.6.0-openjdk 2016-01-26 Oracle ELSA-2016-0067 java-1.6.0-openjdk 2016-01-26 CentOS CESA-2016:0067 java-1.6.0-openjdk 2016-01-26 CentOS CESA-2016:0067 java-1.6.0-openjdk 2016-01-26 CentOS CESA-2016:0067 java-1.6.0-openjdk 2016-01-26 Red Hat RHSA-2016:0067-01 java-1.6.0-openjdk 2016-01-26 Scientific Linux SLSA-2016:0049-1 java-1.8.0-openjdk 2016-01-21 Scientific Linux SLSA-2016:0054-1 java-1.7.0-openjdk 2016-01-21 Scientific Linux SLSA-2016:0053-1 java-1.7.0-openjdk 2016-01-21 Oracle ELSA-2016-0050 java-1.8.0-openjdk 2016-01-21 Oracle ELSA-2016-0054 java-1.7.0-openjdk 2016-01-21 Oracle ELSA-2016-0054 java-1.7.0-openjdk 2016-01-21 Oracle ELSA-2016-0053 java-1.7.0-openjdk 2016-01-21 CentOS CESA-2016:0050 java-1.8.0-openjdk 2016-01-21 CentOS CESA-2016:0049 java-1.8.0-openjdk 2016-01-21 CentOS CESA-2016:0054 java-1.7.0-openjdk 2016-01-21 CentOS CESA-2016:0054 java-1.7.0-openjdk 2016-01-21 CentOS CESA-2016:0053 java-1.7.0-openjdk 2016-01-21 Scientific Linux SLSA-2016:0050-1 java-1.8.0-openjdk 2016-01-20 Oracle ELSA-2016-0049 java-1.8.0-openjdk 2016-01-20 Red Hat RHSA-2016:0055-01 java-1.8.0-oracle 2016-01-21 Red Hat RHSA-2016:0050-01 java-1.8.0-openjdk 2016-01-20 Red Hat RHSA-2016:0049-01 java-1.8.0-openjdk 2016-01-20 Red Hat RHSA-2016:0056-01 java-1.7.0-oracle 2016-01-21 Red Hat RHSA-2016:0054-01 java-1.7.0-openjdk 2016-01-21 Red Hat RHSA-2016:0053-01 java-1.7.0-openjdk 2016-01-21 Red Hat RHSA-2016:0057-01 java-1.6.0-sun 2016-01-21 SUSE SUSE-SU-2016:0776-1 java-1_6_0-ibm 2016-03-15 SUSE SUSE-SU-2016:0770-1 java-1_6_0-ibm 2016-03-15 Gentoo 201603-14 icedtea 2016-03-13 SUSE SUSE-SU-2016:0636-1 java-1_7_0-ibm 2016-03-02 Debian DSA-3725-1 icu 2016-11-27 SUSE SUSE-SU-2016:0431-1 java-1_6_0-ibm 2016-02-11 SUSE SUSE-SU-2016:0433-1 java-1_7_0-ibm 2016-02-11 SUSE SUSE-SU-2016:0428-1 java-1_6_0-ibm 2016-02-11 SUSE SUSE-SU-2016:0399-1 java-1_7_1-ibm 2016-02-10 SUSE SUSE-SU-2016:0401-1 java-1_7_1-ibm 2016-02-10 SUSE SUSE-SU-2016:0390-1 java-1_8_0-ibm 2016-02-09 Mageia MGASA-2016-0048 java-1.8.0-openjdk/copy-jdk-configs/lua-lunit/lua-posix 2016-02-05 Debian-LTS DLA-410-1 openjdk-6 2016-02-04 Debian DSA-3465-1 openjdk-6 2016-02-02 Ubuntu USN-2884-1 openjdk-7 2016-02-01 Ubuntu USN-2885-1 openjdk-6 2016-02-01

Comments (none posted)

java: unspecified

Package(s):	java-1.8.0-openjdk	CVE #(s):
Created:	January 25, 2016	Updated:	January 27, 2016
Description:	From the Fedora advisory: security update to CPU 19.1.2016 to u71b15
Alerts:	Fedora FEDORA-2016-3ea667977a java-1.8.0-openjdk 2016-01-26 Fedora FEDORA-2016-946b98126d java-1.8.0-openjdk 2016-01-24

Comments (none posted)

jenkins: multiple vulnerabilities

Package(s):	jenkins	CVE #(s):	CVE-2014-1869 CVE-2014-3661 CVE-2014-3662 CVE-2014-3663 CVE-2014-3664 CVE-2014-3666 CVE-2014-3667 CVE-2014-3680 CVE-2014-3681 CVE-2016-1905 CVE-2016-1906
Created:	January 27, 2016	Updated:	January 27, 2016
Description:	From the CVE entries: Multiple cross-site scripting (XSS) vulnerabilities in ZeroClipboard.swf in ZeroClipboard before 1.3.2, as maintained by Jon Rohan and James M. Greene, allow remote attackers to inject arbitrary web script or HTML via vectors related to certain SWF query parameters (aka loaderInfo.parameters). (CVE-2014-1869) CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote attackers to cause a denial of service (thread consumption) via vectors related to a CLI handshake. (CVE-2014-3661) CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote attackers to enumerate user names via vectors related to login attempts. (CVE-2014-3662) CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote authenticated users with the Job/CONFIGURE permission to bypass intended restrictions and create or destroy arbitrary jobs via unspecified vectors. (CVE-2014-3663) Directory traversal vulnerability in CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote authenticated users with the Overall/READ permission to read arbitrary files via unspecified vectors. (CVE-2014-3664) CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote attackers to execute arbitrary code via a crafted packet to the CLI channel. (CVE-2014-3666) CloudBees Jenkins before 1.583 and LTS before 1.565.3 does not properly prevent downloading of plugins, which allows remote authenticated users with the Overall/READ permission to obtain sensitive information by reading the plugin code. (CVE-2014-3667) CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote authenticated users with the Job/READ permission to obtain the default value for the password field of a parameterized job by reading the DOM. (CVE-2014-3680) Cross-site scripting (XSS) vulnerability in CloudBees Jenkins before 1.583 and LTS before 1.565.3 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. (CVE-2014-3681) From the Red Hat advisory: An authorization flaw was discovered in Kubernetes; the API server did not properly check user permissions when handling certain requests. An authenticated remote attacker could use this flaw to gain additional access to resources such as RAM and disk space. (CVE-2016-1905) An authorization flaw was discovered in Kubernetes; the API server did not properly check user permissions when handling certain build- configuration strategies. A remote attacker could create build configurations with strategies that violate policy. Although the attacker could not launch the build themselves (launch fails when the policy is violated), if the build configuration files were later launched by other privileged services (such as automated triggers), user privileges could be bypassed allowing attacker escalation. (CVE-2016-1906)
Alerts:	Red Hat RHSA-2016:0070-01 RHOSE 2016-01-26 Red Hat RHSA-2016:0351-01 kubernetes 2016-03-03

Comments (none posted)

mariadb: multiple vulnerabilities

Package(s):	mariadb-10.0	CVE #(s):	CVE-2016-0505 CVE-2016-0546 CVE-2016-0596 CVE-2016-0597 CVE-2016-0598 CVE-2016-0600 CVE-2016-0606 CVE-2016-0608 CVE-2016-0609 CVE-2016-0616 CVE-2016-2047
Created:	January 26, 2016	Updated:	June 27, 2016
Description:	From the Debian advisory: Several issues have been discovered in the MariaDB database server. The vulnerabilities are addressed by upgrading MariaDB to the new upstream version 10.0.23. Please see the MariaDB 10.0 Release Notes for further details.
Alerts:	Red Hat RHSA-2016:1480-01 mysql55-mysql 2016-07-25 Red Hat RHSA-2016:1481-01 mariadb55-mariadb 2016-07-25 openSUSE openSUSE-SU-2016:1686-1 mariadb 2016-06-27 openSUSE openSUSE-SU-2016:1664-1 mariadb 2016-06-23 Debian-LTS DLA-409-1 mysql-5.5 2016-02-01 Debian DSA-3459-1 mysql-5.5 2016-01-28 Ubuntu USN-2881-1 mysql-5.5, mysql-5.6 2016-01-26 Debian DSA-3453-1 mariadb-10.0 2016-01-25 Red Hat RHSA-2016:1132-01 rh-mariadb100-mariadb 2016-05-26 openSUSE openSUSE-SU-2016:1332-1 mysql-community-server 2016-05-18 Fedora FEDORA-2016-1aaf308de4 community-mysql 2016-05-16 Fedora FEDORA-2016-7c48036d73 community-mysql 2016-05-15 SUSE SUSE-SU-2016:1279-1 mysql 2016-05-11 Debian-LTS DLA-447-1 mysql-5.5 2016-04-30 Red Hat RHSA-2016:0705-01 rh-mysql56-mysql 2016-05-02 Debian DSA-3557-1 mysql-5.5 2016-04-26 Ubuntu USN-2954-1 mysql-5.7 2016-04-25 Ubuntu USN-2953-1 mysql-5.5, mysql-5.6 2016-04-21 CentOS CESA-2016:0534 mariadb 2016-03-31 Scientific Linux SLSA-2016:0534-1 mariadb 2016-04-04 Oracle ELSA-2016-0534 mariadb 2016-03-31 Red Hat RHSA-2016:0534-01 mariadb 2016-04-01 Fedora FEDORA-2016-65a1f22818 community-mysql 2016-03-09 Fedora FEDORA-2016-5cb344dd7e community-mysql 2016-03-09 Fedora FEDORA-2016-868c170507 mariadb 2016-03-05 Fedora FEDORA-2016-e30164d0a2 mariadb 2016-02-21 openSUSE openSUSE-SU-2016:0377-1 MySQL 2016-02-08 openSUSE openSUSE-SU-2016:0367-1 MySQL 2016-02-07

Comments (none posted)

moodle: two vulnerabilities

Package(s):	moodle	CVE #(s):	CVE-2016-0724 CVE-2016-0725
Created:	January 21, 2016	Updated:	February 1, 2016
Description:	From the Mageia advisory: In Moodle before 2.8.10, web services core_enrol_get_course_enrolment_methods and enrol_self_get_instance_info did not check user permission to access hidden courses (CVE-2016-0724). In Moodle before 2.8.10, search string in course management interface was not escaped when being output creating potential for XSS attack (CVE-2016-0725).
Alerts:	Fedora FEDORA-2016-fb2597f4eb moodle 2016-02-01 Fedora FEDORA-2016-1c10ab3c35 moodle 2016-01-30 Mageia MGASA-2016-0029 moodle 2016-01-20

Comments (none posted)

mozilla: multiple vulnerabilities

Package(s):	firefox thunderbird seamonkey	CVE #(s):	CVE-2016-1931 CVE-2016-1933 CVE-2016-1937 CVE-2016-1938 CVE-2016-1939 CVE-2016-1942 CVE-2016-1944 CVE-2016-1945 CVE-2016-1946 CVE-2016-1947
Created:	January 27, 2016	Updated:	February 24, 2016
Description:	From the Ubuntu advisory: Bob Clary, Christian Holler, Nils Ohlmeier, Gary Kwong, Jesse Ruderman, Carsten Book, Randell Jesup, Nicolas Pierron, Eric Rescorla, Tyson Smith, and Gabor Krizsanits discovered multiple memory safety issues in Firefox. If a user were tricked in to opening a specially crafted website, an attacker could potentially exploit these to cause a denial of service via application crash, or execute arbitrary code with the privileges of the user invoking Firefox. (CVE-2016-1930, CVE-2016-1931) Gustavo Grieco discovered an out-of-memory crash when loading GIF images in some circumstances. If a user were tricked in to opening a specially crafted website, an attacker could exploit this to cause a denial of service. (CVE-2016-1933) It was discovered that a delay was missing when focusing the protocol handler dialog. If a user were tricked in to opening a specially crafted website, an attacker could potentially exploit this to conduct clickjacking attacks. (CVE-2016-1937) Hanno Böck discovered that calculations with mp_div and mp_exptmod in NSS produce incorrect results in some circumstances, resulting in cryptographic weaknesses. (CVE-2016-1938) Nicholas Hurley discovered that Firefox allows for control characters to be set in cookie names. An attacker could potentially exploit this to conduct cookie injection attacks on some web servers. (CVE-2016-1939) It was discovered that when certain invalid URLs are pasted in to the addressbar, the addressbar contents may be manipulated to show the location of arbitrary websites. An attacker could potentially exploit this to conduct URL spoofing attacks. (CVE-2016-1942) Ronald Crane discovered three vulnerabilities through code inspection. If a user were tricked in to opening a specially crafted website, an attacker could potentially exploit these to cause a denial of service via application crash, or execute arbitrary code with the privileges of the user invoking Firefox. (CVE-2016-1944, CVE-2016-1945, CVE-2016-1946) François Marier discovered that Application Reputation lookups didn't work correctly, disabling warnings for potentially malicious downloads. An attacker could potentially exploit this by tricking a user in to downloading a malicious file. Other parts of the Safe Browsing feature were unaffected by this. (CVE-2016-1947)
Alerts:	openSUSE openSUSE-SU-2016:0306-1 firefox 2016-02-02 Debian DSA-3688-1 nss 2016-10-05 Gentoo 201701-46 nss 2017-01-19 Fedora FEDORA-2016-f2980b4099 firefox 2016-02-02 Fedora FEDORA-2016-c12fa80d79 firefox 2016-01-30 Ubuntu USN-2880-1 firefox 2016-01-27 Gentoo 201605-06 nss 2016-05-31 Ubuntu USN-2973-1 thunderbird 2016-05-19 Debian-LTS DLA-480-1 nss 2016-05-18 Debian-LTS DLA-427-1 nss 2016-02-24 Ubuntu USN-2903-2 nss 2016-02-23 Fedora FEDORA-2016-4aeba0f53d thunderbird 2016-02-21 Arch Linux ASA-201602-16 thunderbird 2016-02-21 Ubuntu USN-2903-1 nss 2016-02-17 Ubuntu USN-2880-2 firefox 2016-02-08 SUSE SUSE-SU-2016:0334-1 MozillaFirefox, MozillaFirefox-branding-SLED, mozilla-nss 2016-02-04 SUSE SUSE-SU-2016:0338-1 MozillaFirefox, MozillaFirefox-branding-SLE, mozilla-nss 2016-02-04 openSUSE openSUSE-SU-2016:0309-1 firefox 2016-02-02

Comments (none posted)

mozilla: code execution

Package(s):	firefox thunderbird seamonkey	CVE #(s):	CVE-2016-1930 CVE-2016-1935
Created:	January 27, 2016	Updated:	February 22, 2016
Description:	From the Red Hat advisory: Several flaws were found in the processing of malformed web content. A web page containing malicious content could cause Firefox to crash or, potentially, execute arbitrary code with the privileges of the user running Firefox. (CVE-2016-1930, CVE-2016-1935)
Alerts:	openSUSE openSUSE-SU-2016:0306-1 firefox 2016-02-02 Fedora FEDORA-2016-f2980b4099 firefox 2016-02-02 Fedora FEDORA-2016-c12fa80d79 firefox 2016-01-30 Mageia MGASA-2016-0041 firefox 2016-01-29 Scientific Linux SLSA-2016:0071-1 firefox 2016-01-27 Oracle ELSA-2016-0071 firefox 2016-01-27 Oracle ELSA-2016-0071 firefox 2016-01-27 Oracle ELSA-2016-0071 firefox 2016-01-27 Debian DSA-3457-1 iceweasel 2016-01-27 Ubuntu USN-2880-1 firefox 2016-01-27 CentOS CESA-2016:0071 firefox 2016-01-27 CentOS CESA-2016:0071 firefox 2016-01-27 CentOS CESA-2016:0071 firefox 2016-01-27 Red Hat RHSA-2016:0071-01 firefox 2016-01-27 Gentoo 201605-06 nss 2016-05-31 Ubuntu USN-2904-1 thunderbird 2016-03-08 Debian DSA-3491-1 icedove 2016-02-24 Fedora FEDORA-2016-4aeba0f53d thunderbird 2016-02-21 Arch Linux ASA-201602-16 thunderbird 2016-02-21 Oracle ELSA-2016-0258 thunderbird 2016-02-18 Oracle ELSA-2016-0258 thunderbird 2016-02-18 CentOS CESA-2016:0258 thunderbird 2016-02-19 CentOS CESA-2016:0258 thunderbird 2016-02-18 CentOS CESA-2016:0258 thunderbird 2016-02-18 Scientific Linux SLSA-2016:0258-1 thunderbird 2016-02-18 Red Hat RHSA-2016:0258-01 thunderbird 2016-02-18 Mageia MGASA-2016-0078 thunderbird 2016-02-17 openSUSE openSUSE-SU-2016:0488-1 Thunderbird 2016-02-17 openSUSE openSUSE-SU-2016:0492-1 thunderbird 2016-02-17 Ubuntu USN-2880-2 firefox 2016-02-08 SUSE SUSE-SU-2016:0334-1 MozillaFirefox, MozillaFirefox-branding-SLED, mozilla-nss 2016-02-04 SUSE SUSE-SU-2016:0338-1 MozillaFirefox, MozillaFirefox-branding-SLE, mozilla-nss 2016-02-04 openSUSE openSUSE-SU-2016:0310-1 xulrunner 2016-02-02 openSUSE openSUSE-SU-2016:0309-1 firefox 2016-02-02

Comments (none posted)

mysql: multiple vulnerabilities

Package(s):	mysql-5.5, mysql-5.6	CVE #(s):	CVE-2016-0503 CVE-2016-0504 CVE-2016-0595 CVE-2016-0607 CVE-2016-0610 CVE-2016-0611
Created:	January 26, 2016	Updated:	January 27, 2016
Description:	Multiple security issues were discovered in MySQL. See MySQL 5.5 release notes and MySQL 5.6 release notes for details.
Alerts:	Ubuntu USN-2881-1 mysql-5.5, mysql-5.6 2016-01-26 Red Hat RHSA-2016:1132-01 rh-mariadb100-mariadb 2016-05-26 Red Hat RHSA-2016:0705-01 rh-mysql56-mysql 2016-05-02 Fedora FEDORA-2016-65a1f22818 community-mysql 2016-03-09 Fedora FEDORA-2016-5cb344dd7e community-mysql 2016-03-09 Fedora FEDORA-2016-868c170507 mariadb 2016-03-05 Fedora FEDORA-2016-e30164d0a2 mariadb 2016-02-21 openSUSE openSUSE-SU-2016:0377-1 MySQL 2016-02-08 openSUSE openSUSE-SU-2016:0367-1 MySQL 2016-02-07

Comments (none posted)

nginx: denial of service

Package(s):	nginx	CVE #(s):	CVE-2016-0742
Created:	January 27, 2016	Updated:	January 28, 2016
Description:	From the Debian LTS advisory: It was discovered that there was a invalid pointer deference in nginx, a small, powerful, scalable web/proxy server. An invalid pointer dereference might occur during DNS server response processing, allowing an attacker who is able to forge UDP packets from the DNS server to cause worker process crash.
Alerts:	Red Hat RHSA-2016:1425-01 rh-nginx18-nginx 2016-07-14 Fedora FEDORA-2016-fd3428577d nginx 2016-01-30 Arch Linux ASA-201601-31 nginx 2016-01-27 Debian-LTS DLA-404-1 nginx 2016-01-27 Gentoo 201606-06 nginx 2016-06-17 Mageia MGASA-2016-0065 nginx 2016-02-17 Debian DSA-3473-1 nginx 2016-02-11 Ubuntu USN-2892-1 nginx 2016-02-09 openSUSE openSUSE-SU-2016:0371-1 nginx 2016-02-07 Fedora FEDORA-2016-bf03932bb3 nginx 2016-02-05

Comments (none posted)

ntp: missing check for zero originate timestamp

Package(s):	ntp	CVE #(s):	CVE-2015-8138
Created:	January 25, 2016	Updated:	November 11, 2016
Description:	From the Red Hat advisory: It was discovered that ntpd as a client did not correctly check the originate timestamp in received packets. A remote attacker could use this flaw to send a crafted packet to an ntpd client that would effectively disable synchronization with the server, or push arbitrary offset/delay measurements to modify the time on the client.
Alerts:	Oracle ELSA-2016-2583 ntp 2016-11-10 Ubuntu USN-3096-1 ntp 2016-10-05 SUSE SUSE-SU-2016:2094-1 yast2-ntp-client 2016-08-17 SUSE SUSE-SU-2016:1912-1 ntp 2016-07-29 Debian-LTS DLA-559-1 ntp 2016-07-25 Debian DSA-3629-1 ntp 2016-07-25 Gentoo 201607-15 ntp 2016-07-20 Fedora FEDORA-2016-8bb1932088 ntp 2016-01-30 Mageia MGASA-2016-0039 ntp 2016-01-29 Oracle ELSA-2016-0063 ntp 2016-01-25 Scientific Linux SLSA-2016:0063-1 ntp 2016-01-25 Oracle ELSA-2016-0063 ntp 2016-01-25 CentOS CESA-2016:0063 ntp 2016-01-25 CentOS CESA-2016:0063 ntp 2016-01-25 Red Hat RHSA-2016:0063-01 ntp 2016-01-25 openSUSE openSUSE-SU-2016:1423-1 ntp 2016-05-27 SUSE SUSE-SU-2016:1311-1 ntp 2016-05-17 Oracle ELSA-2016-0780 ntp 2016-05-13 openSUSE openSUSE-SU-2016:1292-1 ntp 2016-05-12 SUSE SUSE-SU-2016:1247-1 ntp 2016-05-06 Slackware SSA:2016-120-01 ntp 2016-04-29 SUSE SUSE-SU-2016:1177-1 ntp 2016-04-28 SUSE SUSE-SU-2016:1175-1 ntp 2016-04-28 Slackware SSA:2016-054-04 ntp 2016-02-23 Fedora FEDORA-2016-34bc10a2c8 ntp 2016-02-21

Comments (none posted)

opensmtpd: multiple vulnerabilities

Package(s):	opensmtpd	CVE #(s):
Created:	January 27, 2016	Updated:	January 27, 2016
Description:	From the Gentoo advisory: Multiple vulnerabilities have been discovered in OpenSMTPD. A remote attacker could possibly execute arbitrary code with the privileges of the process, or cause a Denial of Service condition.
Alerts:	Gentoo 201601-04 opensmtpd 2016-01-27

Comments (none posted)

owncloud: multiple vulnerabilities

Package(s):	owncloud	CVE #(s):
Created:	January 25, 2016	Updated:	January 27, 2016
Description:	From the ownCloud security advisories: OC-SA-2016-001: A Cross-site scripting (XSS) vulnerability in the OCS discovery provider in ownCloud Servers allows remote attackers to inject arbitrary web script or HTML via the URL resulting in a reflected Cross-Site-Scripting. OC-SA-2016-002: Due to an incorrect usage of an ownCloud internal file system function the passed path to the file scanner was resolved relatively. An authenticated adversary may thus be able to get a listing of files existing on the filesystem. However, it is not possible to access any of these files. This causes a massive server load and thus an enumeration of the whole server content is unlikely due to the high risk of Denial of Service. OC-SA-2016-003: Due to a incorrect usage of the getOwner function of the ownCloud virtual filesystem,done authenticated users with incoming shares of other users are able to access files beginning with ".v" of the sharing user. This can only be exploited if the "files_versions" application is enabled on the server. OC-SA-2016-004: ownCloud returns exception error messages to the user in two different places, allowing an authenticated adversary to gain information about the installation path of the ownCloud instance. There is no further information disclosure.
Alerts:	Fedora FEDORA-2016-9422448006 owncloud 2016-01-24 Fedora FEDORA-2016-a576196426 owncloud 2016-01-24

Comments (none posted)

privoxy: two denial of service flaws

Package(s):	privoxy	CVE #(s):	CVE-2016-1982 CVE-2016-1983
Created:	January 25, 2016	Updated:	February 9, 2016
Description:	From the Arch Linux advisory: - CVE-2016-1982 (denial of service): A vulnerability was discovered in a way the privoxy deals with corrupted chunk-encoded content. A maliciously crafted input can result in a remote denial of service. - CVE-2016-1983 (denial of service): A vulnerability was found in a way the privoxy processes specific client requests. A request with "Host" header empty could result in an invalid read.
Alerts:	Fedora FEDORA-2016-bc7acd24c6 privoxy 2016-02-01 Fedora FEDORA-2016-29995fbd42 privoxy 2016-02-01 Debian DSA-3460-1 privoxy 2016-01-30 Debian-LTS DLA-398-1 privoxy 2016-01-23 Arch Linux ASA-201601-27 privoxy 2016-01-25 Mageia MGASA-2016-0055 privoxy 2016-02-09 openSUSE openSUSE-SU-2016:0311-1 Privoxy 2016-02-02 openSUSE openSUSE-SU-2016:0305-1 privoxy 2016-02-02

Comments (none posted)

qemu: denial of service

Package(s):	qemu	CVE #(s):	CVE-2016-1922 CVE-2015-8701
Created:	January 25, 2016	Updated:	January 27, 2016
Description:	From the Red Hat bugzilla: CVE-2016-1922: Qemu emulator built with the TPR optimization for 32-bit Windows guests support is vulnerable to a null pointer dereference flaw. It occurs while doing I/O port write operations via hmp interface. In that, 'current_cpu' remains null, which leads to the null pointer dereference. A user/process could use this flaw to crash the Qemu instance, resulting in DoS issue. CVE-2015-8701: Qemu emulator built with the Rocker switch emulation support is vulnerable to an off-by-one error. It happens while processing transmit(tx) descriptors in 'tx_consume' routine, if a descriptor was to have more than allowed (ROCKER_TX_FRAGS_MAX=16)fragments. A privileged user inside guest could use this flaw to cause memory leakage on the host or crash the Qemu process instance resulting in DoS issue.
Alerts:	SUSE SUSE-SU-2016:1785-1 kvm 2016-07-11 openSUSE openSUSE-SU-2016:1750-1 qemu 2016-07-06 SUSE SUSE-SU-2016:1703-1 qemu 2016-06-29 SUSE SUSE-SU-2016:1698-1 kvm 2016-06-28 Fedora FEDORA-2016-42778e8c82 qemu 2016-01-24 SUSE SUSE-SU-2016:1560-1 qemu 2016-06-13 Mageia MGASA-2016-0176 qemu 2016-05-18 SUSE SUSE-SU-2016:1318-1 xen 2016-05-17 SUSE SUSE-SU-2016:0955-1 xen 2016-04-05 Gentoo 201604-01 qemu 2016-04-02 SUSE SUSE-SU-2016:0873-1 xen 2016-03-24 Fedora FEDORA-2016-38b20aa50f xen 2016-03-19 Fedora FEDORA-2016-f4504e9445 xen 2016-03-20 Debian DSA-3470-1 qemu-kvm 2016-02-08 Debian DSA-3471-1 qemu 2016-02-08 Debian DSA-3469-1 qemu 2016-02-08 Gentoo 201602-01 qemu 2016-02-04 Ubuntu USN-2891-1 qemu, qemu-kvm 2016-02-03 Fedora FEDORA-2016-275e9ff483 qemu 2016-02-02

Comments (none posted)

tiff: denial of service

Package(s):	tiff	CVE #(s):	CVE-2015-7554
Created:	January 25, 2016	Updated:	January 27, 2016
Description:	From the CVE entry: The _TIFFVGetField function in tif_dir.c in libtiff 4.0.6 allows attackers to cause a denial of service (invalid memory write and crash) or possibly have unspecified other impact via crafted field data in an extension tag in a TIFF image.
Alerts:	Debian-LTS DLA-692-1 tiff3 2016-11-02 Debian-LTS DLA-693-1 tiff 2016-11-02 Mageia MGASA-2016-0349 libtiff 2016-10-21 Scientific Linux SLSA-2016:1546-1 libtiff 2016-08-03 Scientific Linux SLSA-2016:1547-1 libtiff 2016-08-02 Oracle ELSA-2016-1546 libtiff 2016-08-02 CentOS CESA-2016:1547 libtiff 2016-08-02 CentOS CESA-2016:1546 libtiff 2016-08-02 Red Hat RHSA-2016:1547-01 libtiff 2016-08-02 Red Hat RHSA-2016:1546-01 libtiff 2016-08-02 openSUSE openSUSE-SU-2016:0252-1 tiff 2016-01-26 openSUSE openSUSE-SU-2016:0215-1 tiff 2016-01-24 openSUSE openSUSE-SU-2016:0212-1 tiff 2016-01-24 Gentoo 201701-16 tiff 2017-01-09 openSUSE openSUSE-SU-2016:3035-1 tiff 2016-12-07

Comments (none posted)

virtualbox: unspecified vulnerabilities

Package(s):	virtualbox	CVE #(s):	CVE-2016-0495 CVE-2016-0592
Created:	January 25, 2016	Updated:	January 27, 2016
Description:	From the CVE entries: Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 4.3.36 and 5.0.14 allows remote attackers to affect availability via unknown vectors related to Core. (CVE-2016-0495) Unspecified vulnerability in the Oracle VM VirtualBox component in Oracle Virtualization VirtualBox before 4.3.36 and before 5.0.14 allows local users to affect availability via unknown vectors related to Core. (CVE-2016-0592)
Alerts:	Debian DSA-3454-1 virtualbox 2016-01-27 Mageia MGASA-2016-0035 virtualbox 2016-01-23

Comments (none posted)

Kernel release status

The current development kernel is 4.5-rc1, released on January 24. The 4.5 merge window is now closed. Linus said: "It's a fairly normal release - neither unusually big or unusually small. The statistics look fairly normal too, with drivers being a bit over 70% of the bulk (the big driver areas being gpu, networking, sound, staging, fbdev, but its all over)."

Stable updates: 4.3.4, 4.1.16, 3.14.59, and 3.10.95 were all released on January 23. The 4.4.1, 4.3.5, 4.1.17, 3.14.60, and 3.10.96 updates are in the review process as of this writing; they can be expected on or after January 29. Greg Kroah-Hartman warns: "There are still a lot of pending stable patches in the queue, well over 400 of them to be specific, so some of your favorite/pet patches might not be included in these releases." One should thus expect more stable updates in the near future.

Comments (none posted)

Quotes of the week

— Paul McKenney

— Avi Kivity

Comments (none posted)

4.5 merge window part 3

As expected, Linus released the 4.5-rc1 development kernel and closed the merge window for this cycle on January 24. Less than 2,000 changes were pulled since last week's summary, but there were some significant changes to be found among them. Some of the more interesting changes include:

• A new tool called UBSAN checks a running kernel for various types of undefined behavior that can lead to obscure bugs; the commit changelog contains a list of bugs that have already been found by UBSAN and fixed. See Documentation/ubsan.txt for an introduction to this tool.

• The new CONFIG_IO_STRICT_DEVMEM option, which blocks access to memory (via /dev/mem) claimed by device drivers, turned out to break booting on some systems, so it is now off by default.

• The ARM multiplatform work, which aims to build a single ARM kernel that can boot on a wide variety of processors, has reached an important milestone with the merging of work to bring a number of minor platforms into the fold.
  This branch is the culmination of 5 years of effort to bring the ARMv6 and ARMv7 platforms together such that they can all be enabled and boot the same kernel. It has been a tremendous amount of cleanup and refactoring by a huge number of people, and creation of several new (and major) subsystems to better abstract out all the platform details in an appropriate manner.

• The filesystems in user space (FUSE) subsystem has added support for the SEEK_HOLE and SEEK_DATA options to the lseek() system call.

• The epoll_ctl() system call supports a new flag, EPOLLEXCLUSIVE, that causes epoll_wait() to only wake one process when a file descriptor becomes ready. See this article for a description of this option and the use case for it.

• Direct-access ("DAX") mappings now work properly with the msync() and fsync() system calls.

• The ext4 filesystem has gained "project quota" support, wherein dispersed files can be assigned to the same "project" and given their own quota. The feature is rigorously undocumented, but some information be found in the header of this patch posting.

• The implementation of the XFS XFS_IOC_FSSETXATTR and XFS_IOC_FSGETXATTR ioctl() commands has been moved up to the virtual filesystem level, and an implementation for the ext4 filesystem has been added. This operation, also severely undocumented, allows the querying (and setting) of various file attributes, including immutability, whether writes should always be synchronous, exclusion from backups, and more. See the defines near the top of this commit for the list of supported attributes.

• The Ceph filesystem now has support for asynchronous I/O.

• New hardware support includes:
  • Systems and processors: Renesas R-Car H3 systems, Ralink MT7621 processors, Microchip PIC32MZDA processors, Socionext UniPhier systems, and NVIDIA Tegra132 processors.

  • Miscellaneous: Qualcomm "shared memory state machine" controllers, Qualcomm wireless connectivity subsystem controllers, Qualcomm PCIe controllers, TI AMx3 Wkup-M3 inter-processor communication subsystems, Raspberry Pi power domain controllers, TI OMAP dual-mode timers, HiSilicon Hip06 PCIe host controllers, Intel "volume management device" PCI host bridges, and AMD "non-transparent bridge" performance-monitoring hardware.

Finally, back in December, Linus noticed that the user-space access utilities (get_user() and friends) were showing up heavily on some profiles, especially on systems where supervisor-mode access prevention is in use. The problem is that, often, the kernel needs to perform several accesses in a sequence, with the result that access prevention is turned off and back on numerous times.

The solution, as is so often the case, is batching: turn off access prevention once, do all the work, then turn it back on. To support this mode of access, Linus has introduced a new set of macros:

    user_access_begin();
    unsafe_put_user(value, user_space_pointer);
    unsafe_get_user(value, user_space_pointer);
    user_access_end();

As he puts it in the comments, the "unsafe" functions are not actually unsafe if they are used correctly, but developers must pay attention. The unsafe_put_user() and unsafe_get_user() macros can only be used after a user_access_begin() call is made, and the usual access_ok() checks must be done first. The first use of these functions is in the user-space string-manipulation functions. Only x86 is supported in 4.5, but support for other architectures should be forthcoming.

At the close of the merge window, 10,305 non-merge changesets had been pulled into the mainline repository. That suggests that 4.5 will be a relatively slow development cycle with regard to the number of changes merged. Much of that "slowness" can be attributed to a relatively small merge from the staging tree this time around; otherwise, the kernel developers appear to be working at full speed.

If the usual 63-day cycle holds, the release of the final 4.5 kernel can be expected to happen on March 13. Between now and then, though, there are certainly numerous bugs to be found and fixed.

Comments (8 posted)

Controlling access to user namespaces

The user namespaces feature holds an interesting promise for system security: users can be confined within a namespace, given full root privileges within that namespace, and still be unable to adversely affect the system as a whole. The path to better security has, perhaps predictably, proved to be a bit rocky, however. In response, there is now an effort to make the feature configurable by system administrators, but this new configuration knob is proving to be a harder sell than one might expect.

User namespaces are created by passing the CLONE_NEWUSER flag to the clone() or unshare() system calls. Administrators who are nervous about allowing access to this feature currently only have one option: configure out support at kernel build time. That option is not easily available to the many systems running distribution-built kernels, though. Kees Cook set out to create an easier way with this patch set creating a new sysctl knob to control access to the user-namespace feature, saying:

In particular, the patch adds a knob called /proc/sys/kernel/userns_restrict. When it is set to the default value (zero), user namespaces are unrestricted. Setting it to one allows only privileged users to create user namespaces; a setting of two disables user namespaces altogether. In that final case, it is not possible to re-enable user namespaces without rebooting the system.

One of the first issues to be aired had to do with naming: it turns out that Debian currently carries a similar patch, but, on Debian systems, the knob is called unprivileged_userns_clone and doesn't support the "privileged users only" setting. Ben Hutchings agreed that the new naming was probably better and said that, should Kees's patch go upstream, Debian would slowly move over to it.

Some developers worried that allowing user namespaces to be turned off would slow the process of finding and fixing any remaining security issues. Additionally, Serge Hallyn suggested that, if application developers could not count on the availability of user namespaces, they wouldn't use them at all. He suggested that, if the knob is accepted, it be marked as a short-term workaround that would eventually be removed.

The strongest opposition, though, came from Eric Biederman, the creator of user namespaces and also the developer who has done the most work on the sysctl code in recent times. He stated flat out that "the code is buggy, and poorly thought through" and would not be merged. In another message he described his objections in detail, starting with a challenge to the idea that user namespaces are a security risk at all:

Others, though, seem to think that, if problems elsewhere are being "amplified," there is indeed a security exposure. Andy Lutomirski described some concerns of his own:

Eric echoed the point that making it possible to disable user namespaces would be a net loss in security, since the feature would not be available on all systems. He cited web browsing with Chrome as a use case; Kees responded that this patch wasn't really aimed at desktop systems in the first place.

Next on Eric's list was a complaint that a system-wide knob was too coarse; he suggested that perhaps the seccomp() mechanism should be used instead if access to user namespaces must really be restricted. Kees's answer here is that it's not really possible to set a global seccomp() policy, that performance would suffer in any case, and that seccomp() is meant for developers to use rather than system administrators. "It's an extraordinarily big hammer for wanting to turn off a single area of the kernel with a long history of problems." He noted that trying to use a Linux security module to achieve this end would have a number of similar problems.

Then, Eric said, the sysctl knob could create "a false sense of security" since it would have no effect on processes that are already running in a user namespace. If a security issue comes to light, just turning off the knob will not be enough to protect a system; a reboot will also be necessary. Eric returned to this point later, calling the patch "fatally flawed" as a result of the "subtlety and nuance" involved in using it.

Kees acknowledged the "corner case" in the sysctl implementation, one that, he said, applies to a number of other, existing knobs as well. But, he said, it really does not matter to an administrator who simply wants to disable the feature outright as a way of reducing the attack surface of a system. Even so, he allowed: "I'm open to having this sysctl kill all CLONE_NEWUSERed process trees", without noting that having a sysctl knob kill off processes might pose some interesting "subtlety and nuance" of its own.

As a sort of postscript, Eric suggested that, perhaps, the desired restriction could be implemented as a resource limit controlling the number of user namespaces that any user would be allowed to create. Setting that number to zero would effectively disable the feature. Kees indicated a willingness to look at this idea; it is the end result he wants, rather than the sysctl knob itself.

There is an evident desire for the ability to turn off access to user namespaces; various other developers spoke in its favor over the course of the discussion. But this desire is clearly not universal and, as a result, the current patches do not appear to have an easy path into the mainline. It is entirely possible that the concerns blocking this feature may eventually be addressed and overcome, but it also seems possible that, in the end, this knob ends up being part of the patch set carried by distributors and users. It seems that getting security-related changes into the kernel is still a difficult task.

Comments (1 posted)

Next-interrupt prediction

There are many things an operating system would like to know about the future; one of those is when the next interrupt might come in. This information could be put to good use when it comes time to put an idle processor to sleep. Unfortunately, wormhole peripherals that can read information from the future are expensive, so the vast majority of processors are not equipped with them. That leaves no alternative to trying to guess this information using past behavior as a guide.

When a CPU has no work to do, it should go into a sleep state to save power. Modern processors offer a number of sleep states, though, with different characteristics. A shallow sleep is quick to get into and out of, but the power savings offered by shallow sleeps are relatively small. The deeper sleep states can reduce power consumption to nearly zero, but getting a processor back into a running state from a deep sleep state takes a long time and consumes a certain amount of power in its own right. So it only makes sense to enter a deep sleep state if the processor will remain asleep for a relatively long time.

The kernel can never really know how long a processor will be able to sleep, so it has to make its best guess. One way to do that is to look at the next scheduled timer event; that provides an upper bound on how long the processor will remain idle, but it is not the whole picture. The other thing that can wake a processor is an interrupt from a peripheral device (or an interprocessor interrupt (IPI) from another CPU). Current kernels try to take interrupts into account by looking at the length of recent idle cycles; if those cycles are reasonably regular, their length can be taken as a good guess for when the next wakeup will occur.

But, as Daniel Lezcano notes in his IRQ-based wakeup prediction patches, this approach has some shortcomings. It looks only at idle periods without taking the wakeup event into account, so it cannot separate the effects of timer events and interrupts. IPIs factor into the estimate as well, but IPIs are often generated by the scheduler, which is also trying to figure out what the next idle period might be, leading to interesting feedback loops. This approach is also unable to take into account the behavior of individual interrupt sources or to respond to their addition or removal.

Daniel has been working on this problem for a while; he presented one solution at the 2014 Linux Plumbers Conference. His approach at that time was a relatively elaborate, bucket-based system that tracked interrupts associated with each process on the system. There were some complaints at the time that interrupt behavior has more to do with devices than processes, and this work was never pushed into the mainline.

The new approach is conceptually simpler. In short, it tracks the recent interrupt behavior of each device in the system on a per-CPU basis. When the time comes to guess at the length of an idle stretch, each device's behavior is examined separately, and a guess is made regarding which device will interrupt next and when that will happen.

To gather this information, Daniel introduces a new mechanism to track interrupt timings. It is all based around a structure with a handful of functions to be called out of the interrupt-handling subsystem:

    typedef void (*irqt_handler_t)(unsigned int irq, ktime_t time, void *dev_id);
    struct irqtimings_ops {
	int (*alloc)(unsigned int irq);
	void (*free)(unsigned int irq);
	int (*setup)(unsigned int irq, struct irqaction *act);
	void (*remove)(unsigned int irq, void *dev_id);
	irqt_handler_t handler;
    };

Interestingly, there can only be one of these structures in the system, and it must be declared with the DECLARE_IRQ_TIMINGS() macro. This mechanism runs in interrupt mode, so it must do as little work as possible; that means there is no desire to add an elaborate mechanism to call multiple handlers. The creation of a single, global structure also ensures that, if the mechanism is built into the kernel (via the CONFIG_IRQ_TIMINGS parameter), there is also a consumer for the timing information. In the absence of that consumer, the global structure will not be defined, and the kernel build will fail.

The alloc() and free() operations are called when interrupt descriptors (the core data structure for managing interrupt sources) are added to or removed from the kernel. setup() and remove(), instead, are called when the first handler is set up for a given interrupt (or the last one removed). Finally, handler() is called whenever an actual interrupt happens for the given irq number; it is passed a timestamp saying when the interrupt occurred.

On the consumer side (the scheduler's idle-time estimation code), Daniel's patch sets up a data structure that looks like this:

    #define STATS_NR_VALUES 4

    struct stats {
	u64           sum;                     /* sum of values */
	u32           values[STATS_NR_VALUES]; /* array of values */
	unsigned char w_ptr;                   /* current window pointer */
    };

    struct wakeup {
	struct stats stats;
	ktime_t timestamp;
    };

Each CPU gets its own array of wakeup structures, with one entry for each interrupt number. That structure holds the time of the last observed interrupt and the stats structure which, in turn, holds a simple circular buffer of observed interrupt timings.

When the interrupt timing handler is called, it looks up the appropriate wakeup structure. The time since the last interrupt is calculated and inserted into the circular buffer; the sum of all the interrupt timings is updated as well. If it has been more than one second since the previous interrupt, though, the accumulated information is discarded instead and the statistics collection is restarted from the beginning. Once collection has been active for a bit, the code can easily calculate the mean time between interrupts and the variance in that time as well.

In the current patch set, there is no tracking at the level of individual devices; if multiple devices share an interrupt number, they will all appear together in the statistics. That may prove to be a shortcoming on systems with large amounts of interrupt sharing, but it should also be easy to fix should that turn out to be the case. Given that interrupt sharing appears to be slowly fading away, this may not be a concern in the end.

When the time comes to make a guess for the duration of the next idle period for a given CPU, the code iterates through all of the interrupts that have been active on that CPU. For each, the mean time between interrupts and the variance are calculated. If the timing between the last two interrupts was within one standard deviation of the mean, the code concludes that interrupts on this line are predictable; the next interrupt time is then calculated by adding the mean time to the time of the last interrupt. The interrupt that is predicted to happen the soonest is used to make a guess at the expected idle time.

One could certainly try to poke holes in this mechanism. Four samples seems like a small number to be drawing conclusions from. The fact that the algorithm skips over interrupts that seem unpredictable suggests that it might overestimate the length of the coming idle period. Daniel acknowledges some of these limitations, but says: "The statistics are very trivial and could be improved later but this first step shows we have a nice overall improvement in SMP." This mechanism does not show an improvement on uniprocessor systems, though.

There has been a fair amount of discussion around these patches, mostly focused on relatively low-level implementation details (whether timestamps should be kept in microseconds or nanoseconds, for example). One more significant issue is that the simple arrays indexed by interrupt number will not work on some systems with more complex interrupt setups. Instead, Thomas Gleixner said, the code needs to use a radix tree to track interrupt sources.

There does not appear to be opposition to the underlying approach, though. So, once the details have been worked out, this work may get the green light to go into the mainline kernel. Then, perhaps, our batteries will last a little longer, which cannot be a bad thing.

Comments (6 posted)

Tiny Core Linux 7.0

While many general-purpose Linux distributions cater to as broad an audience as possible, a number of lesser-known distributions drop user-friendliness and an "out-of-the-box" system in exchange for other benefits. Tiny Core Linux (TCL) charts a path of minimalism and frugality. It comes with the bare minimum one needs to get a Linux system up and running, which immediately cuts out non-technical users. Instead, as TCL development team member "Curaga" described in a forum post, its users tend to come from one of four groups: "those running old or limited hardware, those needing appliances/VMs for specific purposes, those who want to tinker and customize, and some who are just sick of the software bloat trends" as seen in Linux, Windows, and Mac OS X alike.

With over seven years of history, a team of dedicated developers, a recent 7.0 beta release, and a clearly-defined niche, the project's focus has remained constant through the changes in the information technology world. Indeed, with Linux being ubiquitous on embedded systems, a small distribution to tinker with becomes even more relevant. That tinkering is emphasized in "Into the Core: A Look At Tiny Core Linux", a 163-page e-book guide [PDF] to the distribution. Its back cover gives an idea of what Tiny Core Linux is targeting:

TCL comes in three different "flavors" for download. Core, weighing in at 10MB, is a command-line only experience that will run on 46MB of RAM and an ancient i486DX processor. TinyCore, at 15MB, tacks on a simple Fast Light Window Manager (FLWM) graphical user interface (GUI) along with graphical applications for tasks like package management.

The flavors are intended to be run "live" as with a Live CD, which makes them handy for those working with virtual machines or who simply want a "dumb" Internet terminal. The 86MB CorePlus, which comes as an installation image, offers six additional window managers to choose from, as well as other conveniences such as support for wireless networks and non-US keyboard layouts. The graphical installer takes about a minute to complete its task—considerably faster than its mainstream Linux competitors.

TCL's founder, Robert Shingledecker, offered the details behind the origins of the project in a March 2009 interview for DistroWatch. Shingledecker is a hacker in his sixties who retired after a career in information technology:

In 2004, he became a lead developer of Damn Small Linux (DSL), which is also a minimalist distribution. As a result of "a culmination of personal attacks and accusations against me, disagreements and irreconcilable differences", Shingledecker left the project. Two other DSL members, Kent Porter and Chris Livesay, also left the project to work with Shingledecker on his new project: Tiny Core Linux.

Not based on any other distribution, TCL is "entirely contained in a compressed cpio archive that populates the initial RAM disk upon booting of the Linux kernel". The developers pride themselves on how the system organizes its data; as Curaga put it:

I took all three flavors for a spin in VirtualBox, on a laptop with more than enough power to run the system.

Core impresses with its frugality, booting a kernel in about two seconds to a command line. TCL offers boot codes to configure the system, such as noswap to force the system to not use a swap partition, and multitvt to boot with multiple consoles instead of one. This flavor is the one most-suited to experienced Linux developers and tinkerers; with just the minimum required, Core provides an excellent base for building one's own projects.

TinyCore gave me the opportunity to explore the FLWM GUI it uses, which provides a clean, simple interface with a dock at the bottom. TinyCore is the recommended flavor for less-experienced Linux users with access to a wired network. Its GUI provides the basic graphical applications needed to customize the system.

The most notable is Apps, a graphical package manager for installing additional software; there are a few thousand packages to choose from. On first boot, Apps detects the closest online repository mirror. A number of common useful applications are packaged for the distribution, including text editors, development environments, and web browsers. Unfortunately, Apps is not the most intuitive package manager. One can search for programs by name or by keywords in their .info description file. Otherwise, however, the application list is organized in alphabetical order without any classifications (such as "productivity" or "games") that one would find in a package manager like Synaptic, making an ordinary scroll through the list less than helpful to find packages.

The software selection is smaller than those of Debian-based or Fedora-based distributions; for those needing more choice, there's dCore, an official TCL variant that comes with scripts to download and install Debian or Ubuntu packages from their official repositories. Users preferring to work with the command-line can use the tce-ab command to access package management and download applications. TCL uses its own package format, .tcz, which is unique to the distribution and those derived from it.

TinyCore also offers a terminal application, a simple text editor, a "control panel" for basic system management (like setting the time and choosing a wallpaper), and a program for mounting removable storage. One will not find other pre-installed applications that might be seen on a general-purpose system, such as a web browser, multimedia codecs, or a word processor; TinyCore provides only the necessities.

CorePlus offers a similar experience to TinyCore, but with more window managers to choose from. It also includes applications to facilitate installation onto permanent storage. The wireless drivers included would be certainly handy for many laptop users, and the built-in support for non-US keyboard layouts makes CorePlus a must for interested users with different keyboards. CorePlus gives one an appreciation for the overhead of things that most users take for granted (e.g. GUIs, wireless drivers); booting the system took several seconds longer than TinyCore and Core.

For an example of a use case for TCL, one can look to piCore, a TCL port for the Raspberry Pi. After booting from an SD card, the distribution unmounts the boot partition and just runs from RAM. This provides for an operating system on the Raspberry Pi that runs much faster than its popular alternatives, such as Raspbian, as piCore isn't limited by the speed of an SD card. This makes using the Raspberry Pi as, for example, an Internet terminal, more appealing, as graphical web browsers can be sluggish on the other Raspberry Pi distributions.

The distribution handles security issues on a case-by-case basis, patching software after users raise concerns about vulnerabilities. Some of the more infamous recent security issues, such as bash's Shellshock bugs and OpenSSL's Heartbleed, were addressed within the first few days of their initial disclosures.

While the team responds to the community's raising of security issues and discussions of potential new features, development resources are somewhat sparse. On TCL's "About Us" page, twelve team members (all volunteers) are listed, of which six are developers. Occasionally the team will get a one-off contribution from an outside individual, but as Curaga notes "it's clear the community is not at its peak. We're not really doing things any different than we were in the 2.x/3.x timeframe". Nonetheless, the project does release new versions relatively frequently, with five point releases in the 6.x series in 2015.

Those wanting to pitch in should introduce themselves on the official forums, which serve as a central location for development. The team is open to receiving contributions of all sorts, whether it's "development ideas, patches, bug fixes, testing, submitting extensions, updating wiki, forum assistance ...", as "nitram" put it in a forum post.

Looking forward to 8.0, the project's developers are focusing on maintaining a stable distribution; they are not looking to make radical changes. The distribution numbering system is largely "time-based": there aren't any new major features in 7.0 in comparison to the 6.x series, but there is a newer kernel and GNU toolchain, along with updates to other core libraries.

The forums also provide a showcase for derivatives that people have made using TCL, which demonstrate the versatility of the system. XiniX takes TCL and adds a custom GUI and a few other applications to make a user-friendly "cloud" terminal. Minux turns TCL into a lightweight general-purpose desktop, with minimal software like the Dillo web browser and the mtPaint image editor. One could imagine other uses cases, such as for Internet-of-Things devices or robotics. Those interested in crafting their own Linux distribution can take a look at the "Into The Core" e-book, which provide a guide on how to get started making one's own version of TCL.

Tiny Core Linux is a good demonstration of the bare-bones minimum one needs to set up a functioning, extensible Linux distribution with a package manager, with or without a GUI. It is also a practical toolkit for building derivatives to use for a variety of scenarios. Quoting the back cover of the e-book again: "From digital signage to custom household appliances, from virtual machines to small Android install images, building it your way has never been more convenient." Those interested in making their own minimal distribution have an excellent choice in Tiny Core—especially with a 7.0 stable release just around the corner.

Comments (10 posted)

Debian 8.3 released

The Debian project has announced the third update of its stable distribution Debian 8 "jessie". "This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems. Security advisories were published separately and are referenced where applicable."

Full Story (comments: none)

A couple of notes from the January 22 FESCo meeting

The minutes from the January 22 meeting of the Fedora Engineering Steering Committee (click below for the full text) include a couple of interesting decisions. The first is that "skip-release" upgrading is now officially supported — things should Just Work for users wanting to upgrade their systems once per year. The other is continued discussion on Mozilla's blocking of unsigned plugins; an email will be sent to Mozilla describing Fedora's concerns and suggesting some ways of making things better. In the meantime, Firefox updates will be shipped as usual.

Full Story (comments: none)

Kali Linux, Rolling Edition Released – 2016.1

Kali Linux has announced a switch to a rolling release model and released a snapshot labeled 2016.1. "To get a better understanding of the changes that this brings to Kali, a clearer picture of how rolling releases work is needed. Rather than Kali basing itself off standard Debian releases (such as Debian 7, 8, 9) and going through the cyclic phases of “new, mainstream, outdated”, the Kali rolling release feeds continuously from Debian testing, ensuring a constant flow of the latest package versions." The current stable version 2.0 will no longer be updated and will reach end-of-life on April 15.

Comments (none posted)

Distribution newsletters

• DistroWatch Weekly, Issue 645 (January 25)
• openSUSE Tumbleweed Review 2016/3 (January 24)
• Ubuntu Kernel Team newsletter (January 26)
• Ubuntu Weekly Newsletter, Issue 451 (January 24)

Comments (none posted)

Fast Times With Nelum OS (LinuxInsider)

LinuxInsider takes a look at Nelum OS, a new distribution that comes in three editions; Nelum Openbox 32-bit, based on Debian Sid, Nelum OS 16.04-64, based on Ubuntu 16.04, and Nelum-Bang, a minimalist distribution based on Debian Jessie. "Openbox is the common thread that ties the three versions together, but that doesn't mean the editions are identical. One difference is the range of installed programs. The Nelum Openbox edition has a Control Panel to hold a unified placement of system settings. Nelum OS-16.04-64 edition has a Google Docs entry in the menu. It loads access to all Google Docs apps and spreadsheets from a separate Web browser tab."

Comments (none posted)

Removing support for Emacs unexec from Glibc

The Emacs editor requires a lot of Lisp code and program state before it can start doing its job. That led Emacs developers to add the "unexec" feature to quickly load all of that at startup, but unexec has always been something of a hack. It employs a fairly ugly (and intrusive) mechanism to do its job. Some non-standard extensions to the GNU C library (Glibc) are required, so a plan to eventually eliminate those extensions was met with some dismay in the Emacs community.

As part of the Emacs build process, a simpler version of the editor, called "temacs", is built. That program consists of all of the C files in Emacs, which comprise the Emacs Lisp interpreter and not much else. It is then run to load the standard Lisp startup files and to dump a copy of the running program. That dump is then used as the binary that users invoke when they want to run Emacs.

The mechanism used is in the Emacs unexec() function that converts the running program into a new executable. To do that, it needs to handle memory that was allocated by malloc(), which also requires that the Glibc internal tracking and housekeeping data structures for memory allocation be preserved. The dumping (and restoring) mechanism uses malloc_get_state() and malloc_set_state() to do that, which are the extensions that Glibc developers would like to eliminate.

In mid-January, Florian Weimer posted a heads-up message about the change to the emacs-devel mailing list. He said that it was likely coming this year and was being done to allow changes to the "heap layout between glibc releases, for standards conformance, performance and security improvements". The intent is that existing Emacs binaries will still continue to work, but that at some point the Emacs build would have to change, he continued. He also noted that supporting existing binaries "causes a significant ongoing maintenance overhead for glibc upstream, basically maintaining a separate malloc implementation indefinitely".

Emacs maintainer John Wiegley voiced his concerns that the alterations needed to Emacs would be "a rather significant change to low-level code that has been functioning for a very long time". He suggested extending the timeline for the change and discussing ways to provide the same or similar functionality. Weimer, though, believes that it is "time to tackle it at the root" by fixing Emacs, which is seen as the only user of the interfaces:

A change "forced" on Emacs by another GNU project was always likely to get the attention of Richard Stallman. He emailed the private—and largely unused—mailing list for the Glibc steering committee (glibc-sc), which Mark Brown reposted to the normal Glibc mailing list (libc-alpha). The steering committee does not really exist in the form of that list anymore, which led Carlos O'Donell to suggest that the mailing list be closed. In the reposted message, Stallman largely echoed Wiegley:

Stallman also mentioned that he had contacted the Glibc maintainers in the emacs-devel thread. That led Weimer to wonder why it was appropriate to move the discussion to a private list: "This doesn't really match how glibc development proceeds today." Stallman, though, thought that it would be better discussed in private: "This a sensitive issue; it is best to discuss it without an audience."

That particular cat was out of the bag at that point, however. The conversation in emacs-devel proceeded by looking at the dump/load functionality, whether it is still needed, and ways to implement it that don't require intimate knowledge of the internals of Glibc's memory-allocation techniques.

Ali Bahrami, who works on the Solaris linker, wondered if it even made sense to continue to support the unexec functionality. Computers have gotten a lot faster since that optimization was added, so it might make sense to simply leave it behind:

So Bahrami and others set out to measure the difference between starting Emacs and starting temacs (which must load all of the different startup files). It became clear that there is still a substantial difference; a half second versus more than five seconds, though that depends on various factors. Different tricks were tried, with some success, but the main problem remained.

David Caldwell suggested one possible approach: taking the compiled Lisp files (.elc files) that temacs loads and adding them into the binary.

Stallman seemed interested in that idea, "but the real test is in implementing it".

According to Paul Eggert, making unexec more portable has been on the to-do list for a while, "and this will light more of a fire under it". Concerns that Emacs might not build using a new Glibc API (which has not even been written yet) that came up earlier in the thread are not a problem, he said. "Emacs should still build and run even if the glibc API is changed, as Emacs ./configure probes for the glibc malloc-related API and falls back on its own malloc implementation otherwise."

In another message, Eggert outlined how Emacs uses unexec and how it might be able to get along without it: "Emacs could live without the current unexec in a semi-portable way by doing what XEmacs does, which is to write out data and mmap it in later". He does not know the details of the XEmacs approach, though, and suggested other possibilities as well.

The discussion continued, looking at various ways for Emacs to accomplish its goals without requiring Glibc to maintain the same heap layout forever. If there was a need to consider the matter privately, it certainly wasn't apparent in the thread. As with many changes of this sort, developers on both sides of the change simply worked things out. Perhaps there will be glitches down the road, but there was plenty of notice and it seems like a direction that the Emacs developers wanted to go in anyway, so it is hard to see any major potholes in the road ahead.

Comments (41 posted)

Quotes of the week

I live in Mountain View and the Google Car passes me regularly when I'm rollerblading or cycling, so I have a lot of time to think about whether I want to pull out in front of the Google Car to get around another cyclist. So far I've decided not to.

— Alison Chaiken at SCALE 14x, on the perils of autonomous vehicles.

— Bryan Cantrill, on the perils on unikernels.

— Havoc Pennington

— Nic Collins (hat tip to Hanno Zulla).

Comments (31 posted)

Rust 1.6 released

Version 1.6 of the Rust programming language has been released. "The largest new feature in 1.6 is that libcore is now stable! Rust’s standard library is two-tiered: there’s a small core library, libcore, and the full standard library, libstd, that builds on top of it. libcore is completely platform agnostic, and requires only a handful of external symbols to be defined. Rust’s libstd builds on top of libcore, adding support for memory allocation, I/O, and concurrency. Applications using Rust in the embedded space, as well as those writing operating systems, often eschew libstd, using only libcore. libcore being stabilized is a major step towards being able to write the lowest levels of software using stable Rust."

Comments (5 posted)

PulseAudio 8.0 released

Version 8.0 of the PulseAudio framework is available. New features include systemd journal logging for PulseAudio clients, more flexible configuration-file handling, an interface for balancing low-frequency effects (LFE) channels, and improvements to the D-Bus interface.

Full Story (comments: none)

A change of maintainership for Mercurial

Matt Mackall, the creator of the Mercurial source-code management system, has announced that he is ready to move on to a new project. "So over the course of this year, I'm going to gradually remove myself from daily involvement in the project. As lots of people and companies have a lot invested in Mercurial, I'm doing this over a long period of time to make sure it goes smoothly."

Comments (37 posted)

The Linux Test Project has been released for January 2016

The Linux Test Project test suite stable release for January 2016 is available. There were 191 patches by 29 authors merged since the previous release. Some notable changes include rewritten and new cgroup tests for cpuacct and pids controllers, rewritten basic cgroup functional and stress tests, new userns07 test for user namespaces, new syscall tests, and more.

Full Story (comments: none)

Firefox 44 released

Firefox 44.0 has been released. With this version Firefox can get push notifications from your favorite sites. This release also features improved warning pages for certificate errors and untrusted connections, H.264 is enabled if the system decoder is available, if MP4/H.264 are not supported WebM/VP9 video support is enabled, the brotli compression format via HTTPS content-encoding is supported, and more. See the release notes for details.

Comments (48 posted)

Development newsletters from the past week

• What's cooking in git.git (January 20)
• What's cooking in git.git (January 26)
• GNU Toolchain Update (January)
• LLVM Weekly (January 25)
• OCaml Weekly News (January 26)
• Perl Weekly (January 25)
• PostgreSQL Weekly News (January 24)
• Python Weekly (January 21)
• Ruby Weekly (January 21)
• This Week in Rust (January 25)
• Wikimedia Tech News (January 25)

Comments (none posted)

Hutterer: Is Wayland ready yet?

On his blog, Peter Hutterer answers the perennial "is Wayland ready yet?" question by pointing out that it really is not the right question. "The protocol is stable and has been for a while. But not every compositor and/or toolkit/application speak Wayland yet, so it may not be sufficient for your use-case. So rather than asking 'Is Wayland ready yet', you should be asking: 'Can I run GNOME/KDE/Enlightenment/etc. under Wayland?' That is the right question to ask, and the answer is generally 'It depends what you expect to work flawlessly.' This also means 'people working on Wayland' is often better stated as 'people working on Wayland support in ....'. "

Comments (213 posted)

AMD: It's time to open up the GPU

AMD has launched "gpuopen.com" to support open graphics development (on AMD GPUs, naturally). "The second is a commitment to open source software. The game and graphics development community is an active hub of enthusiastic individuals who believe in the value of sharing knowledge. Full and flexible access to the source of tools, libraries and effects is a key pillar of the GPUOpen philosophy. Only through open source access are developers able to modify, optimize, fix, port and learn from software. The goal? Encouraging innovation and the development of amazing graphics techniques and optimizations in PC games."

Comments (12 posted)

LWN reaches voting age

Just a quick note to point out that the very first LWN Weekly Edition came out on January 22, 1998. So we have now been at it for eighteen years. To say we would have been surprised by that idea in 1998 is a serious understatement. Many thanks to LWN's reader community for keeping us going for all this time!

Comments (36 posted)

Zemlin on the Linux Foundation's by-law changes

Linux Foundation leader Jim Zemlin explains the recent changes in the organization's by-laws. "First, The Linux Foundation Board structure has not changed. The same individuals remain as directors, and the same ratio of corporate to community directors continues as well. What we did do was to act on a long-discussed perception that the value we provide to individual supporters could be improved, for the first time in a decade. And that the process for recruiting community directors should be changed to be in line with other leading organizations in our community and industry." He also speaks out against the personal attacks that have appeared in conversations about this change.

Comments (53 posted)

CFP Deadlines: January 28, 2016 to March 28, 2016

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

Deadline	Event Dates	Event	Location
January 29	April 20 April 21	Vault 2016	Raleigh, NC, USA
February 1	April 25 April 29	OpenStack Summit	Austin, TX, USA
February 1	June 22 June 24	USENIX Annual Technical Conference	Denver, CO, USA
February 1	April 4 April 8	OpenFabrics Alliance Workshop	Monterey, CA, USA
February 2	March 29 March 31	Collaboration Summit	Lake Tahoe, CA, USA
February 5	April 4 April 6	Embedded Linux Conference	San Diego, CA, USA
February 5	April 4 April 6	OpenIoT Summit	San Diego, CA, USA
February 6	February 12 February 14	Linux Vacation / Eastern Europe Winter Edition 2016	Minsk, Belarus
February 8	April 7 April 8	SRECon16	Santa Clara, CA, USA
February 10	April 23 April 24	LinuxFest Northwest	Bellingham, WA, USA
February 12	May 9 May 13	ApacheCon North America	Vancouver, Canada
February 15	March 11 March 13	Zimowisko Linuksowe TLUG	Puck, Poland
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

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

Edward Snowden will kick off LibrePlanet 2016

The Free Software Foundation has announced that the opening keynote for LibrePlanet 2016: Fork the System, will be a conversation with National Security Agency (NSA) whistleblower Edward Snowden and American Civil Liberties Union (ACLU) Technologist Daniel Kahn Gillmor. LibrePlanet will take place March 19-20 in Cambridge, MA.

Full Story (comments: none)

Events: January 28, 2016 to March 28, 2016

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

Date(s)	Event	Location
January 30 January 31	Free and Open Source Developers Meeting	Brussels, Belgium
February 1	MINIXCon 2016	Amsterdam, Netherlands
February 1	Sysadmin Miniconf	Geelong, Australia
February 1 February 5	linux.conf.au	Geelong, Australia
February 5 February 7	DevConf.cz 2016	Brno, Czech Republic
February 10	The Block Chain Conference	San Francisco, CA, USA
February 10 February 12	netdev 1.1	Seville, Spain
February 12 February 14	Linux Vacation / Eastern Europe Winter Edition 2016	Minsk, Belarus
February 24 February 25	AGL Member's Meeting	Tokyo, Japan
February 27	Open Source Days	Copenhagen, Denmark
March 1	Icinga Camp Berlin	Berlin, Germany
March 1 March 6	Internet Freedom Festival	Valencia, Spain
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	PyCon SK 2016	Bratislava, Slovakia
March 11 March 13	Zimowisko Linuksowe TLUG	Puck, Poland
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

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