LWN.net Weekly Edition for April 9, 2015
A different approach to application containers with Limba
Over the past two years, application packaging has become a topic of much debate within the GNOME project. The packaging effort that has garnered perhaps the most attention is the sandboxed applications work done by Alexander Larsson, but it is not the only one. Matthias Klumpp, for example, has been pursuing an application-packaging strategy of his own that takes a different approach. Klumpp's project is called Limba, and a new release was recently unveiled.
Klumpp started working on Limba in November 2014, citing as his inspiration the same proposal that eventually led to Larsson's work. That proposal was Lennart Poettering's blog post about the difficulty of packaging third-party applications for Linux desktops. But Poettering proposed packaging applications into bundles that were quite isolated from the rest of the distribution, an approach Klumpp found problematic. It duplicates shared libraries and other components, makes the running system harder to profile, and, quite simply, bypasses the distribution rather than working with it.
Beaucoup bundles
Larsson and others pursued many of the ideas set out in Poettering's post, with some changes, of course, and the result is the xdg-app tool set, which we looked at in January. Limba bears some resemblance to xdg-app in the broad strokes. Both models bundle the application into a self-contained package that is isolated from the rest of the operating system using various technologies common to other containerization efforts, like SELinux, control groups, and namespaces (specifically, filesystem, process, and network namespaces).
The xdg-app sandbox design, however, relies on the host system providing a static "runtime" environment that will provide each app bundle with the libraries and system resources it requires. The GNOME work in this area has been focused on defining a "GNOME runtime" tailored to each GNOME release— the 3.16 runtime, for example, would receive critical security updates, but app bundles using it can count on it remaining unchanged even after the GNOME 3.18 release and its accompanying runtime make their debut. Other vendors (including, perhaps, Linux distributions as well as other application platforms like KDE) could produce their own runtimes that could also serve as targets for app bundles.
In contrast, Limba's approach lets each application distributor define its own runtime tailored to its app bundle. The runtime definition is dependency-based, much like existing package dependencies are specified today. Thus, the pieces within the runtime can be updated if a new version of some dependency is released.
Practically speaking, these dependencies are specified with XML according to the AppStream metadata format. When the Limba bundle is executed, the controller process is responsible for merging the contents of the bundle, the local libraries, and potentially other Limba bundles into a single OverlayFS filesystem that satisfies the bundle's dependencies. This OverlayFS filesystem is then set up in a mount namespace, inside of which the app bundle is launched.
A Limba bundle's dependencies can be specified as "version X or greater," in addition to matching a specific package version. The bundle can also include its own libraries (a feature that is also supported by xdg-app) for those packages not provided by a distribution repository.
Thus, the Limba bundle represents something of a middle-ground between the locally installed package as provided by most distributions today and the containerized bundle of xdg-app. In a March 30 blog post, Klumpp highlighted some trade-offs he sees between the two designs:
Limba does not have this issue, but instead, with its dynamic runtimes, relies on upstreams behaving nice and not breaking ABIs in security updates, so existing applications continue to be working even with newer software components.
He also points out that a Limba bundle could be made to mimic the behavior of an xdg-app bundle by specifying an exact dependency set that happens to, say, match the contents of the GNOME 3.16 xdg-app runtime.
Current status
Neither Limba nor xdg-app are yet production-ready, of course; both are still undergoing plenty of changes in development. But both are testable. Klumpp released version 0.4.0 in February, which has subsequently been followed by two minor updates. Included at present are the lipkgen tool to both generate a Limba bundle template as well as build the final package, the lipa tool to install bundles, and the runapp command to launch an installed bundle. Because Limba uses OverlayFS, the system does require a kernel built with support for that filesystem.
In the March blog post, Klumpp also provided a real-world application bundle for those interested in testing Limba. The application in question is Neverball, the same video game that Larsson released in an xdg-app bundle in February. Whether or not this series of events will lead to a rise in Neverball bundle tournaments at development events has yet to be seen; hopefully bundles with other types of application will be forthcoming.
It will be interesting to see where Limba goes next. At the moment, it does not have as much of a sandbox system in which to isolate the bundled application, but that is on the agenda and it is worth noting that xdg-app's sandbox is still under construction as well.
Considering how much overlap there is between the designs, one might be tempted to think that the success of the projects would come down to how software distributors feel about the runtime issue. If GNOME (or another project) makes a compelling argument for its all-in-one runtime, that could draw more developers toward xdg-app. But distributors might find it easier to work within the existing package-distribution model, which Limba targets.
In the longer term, though, both projects make a case that their respective bundle format provides a stable platform that the application developer can count on. Whether the large-runtime approach of xdg-app or the more traditional system-provided package environment of Limba provides better stability is something only time will tell.
Realtime using the PRU
Realtime applications on Linux are generally run on the RT_PREEMPT kernel, but Ron Birkett presented an alternative at the 2015 Embedded Linux Conference (ELC) in San Jose: using the programmable realtime unit (PRU) available on some ARM chips. It is, in fact, a popular alternative, as several of the Linux drone makers presenting at the conference were using the PRU to offload various realtime tasks from Linux. That was the main difference Birkett said he noticed from ELC Europe last October—there, he was the only one talking about PRUs.
Birkett introduced himself as a firmware developer, "not a Linux kernel guy", working on Sitara ARM processors for TI. The PRU was specifically designed as a special-purpose RISC processor to help with realtime requirements by minimizing latency response. Beyond that, it is "really cool" what the PRU can do when you hook it up to Linux.
![[Rob Birkett]](https://static.lwn.net/images/2015/elc-birkett-sm.jpg "Rob Birkett")
Realtime does not mean "ultra fast", he reminded attendees. Instead, it means that there is determinism in the system; that events will happen when the system designer thinks they will happen. If you need to get up for work at 6am every day or lose your job, he said, that is a realtime requirement at some level. Typically, though, realtime means more than just deterministic latency; it also means that the response time will be quite low.
But the PRU has not always existed, and we have been making realtime systems for years. Why does the PRU do determinism better than other options? That is a question he was setting out to answer in the talk, he said.
Realtime is typically only one element of the complex systems we are building these days. Getting realtime response requires trading something off, which is throughput. But what if you want both throughput and realtime response? Normally, you can't have both.
The AM355x system-on-chip (SoC) family (as found in the BeagleBone Black) has a Cortex-A8 CPU that is designed for throughput. It has a long, deep pipeline and multiple levels of memory and cache. But cache throws away determinism, he said. That leads to people using a 2GHz processor to solve a 200MHz problem, because they have to look at the worst-case latencies with a cold cache, nothing in the processor pipeline, and slow RAM access.
Enter the PRU. Typically, there are two PRU cores, each with its own dedicated instruction and data RAM, without any caching. There is a dedicated interconnect between the two PRUs, with some shared RAM, an interrupt controller, and some peripherals. The PRU does connect out to the rest of the system, but you lose determinism when you do so. Putting everything required for the realtime portion of the application inside the PRU "box" gives assurances on access times. In the PRU, access to the instruction RAM takes one cycle and the data and shared RAM can be accessed in three cycles.
Each PRU core is a 32-bit RISC processor that runs at 200MHz. There is no pipeline and instructions are executed in a single 5ns cycle. He showed the system diagram for one particular flavor of PRU, which had a scratchpad to move the entire register set between the PRU cores, an interrupt controller, some dedicated peripherals (e.g. a UART), and a fast I/O interface that has 30 general-purpose (GP) inputs and 32 GP outputs per PRU core.
The GPIO controllers have direct access to the pins, unlike other processors where there are multiple levels of controllers and other hardware between the processor and the pin. There are several different input modes including a 16-bit parallel capture. By way of comparison, his team wrote a small program to simply blink an LED attached to a GP pin for both the CPU and the PRU. Looking at the output on an oscilloscope, the 2GHz Cortex-A8 could transition the pin in 200ns, while the PRU could do it in 5ns.
There are lots of different things that can be done with such a device, Birkett said. For drones, one PRU is often used to handle the radio-control interface, while the other is used to drive the pulse-width modulation (PWM) for the motors. There are also dedicated peripherals as part of the PRU that can be used as an extra UART, timer, or PWM controller that is accessible from the Cortex-A8.
The PRU does not support interrupts. Instead, it must poll the interrupt controller to determine if an interrupt has occurred. Polling is more deterministic; asynchronous interrupts can cause jitter in the execution time.
So the PRU makes a great complement to a high-end core like the Cortex-A8, he said. PRUs are available in the AM335x and AM437x and planned for more SoCs in the future.
An audience member asked about support for I2C on the PRU. Birkett said that it is easily done in software on the PRU, as are SPI and other communication protocols. There are no open-source implementations, yet, but there are plans to release code for those over time.
It is not possible to run Linux on the PRU—it doesn't make sense to do so even if you could. Linux will run on the main CPU and communicate with the PRU using interrupts or messages. There is only 8KB of instruction RAM available, so some kind of bare-metal stack in C or assembly makes the most sense. You could run a small realtime operating system (RTOS), but even that might be difficult.
There is a C compiler for the PRU available to use, though it is not free software. There have been a few years worth of work on optimization put into the compiler, so it generates "pretty good code" at this point, Birkett said. There is a GCC version available too, though it lacks the optimizations that the TI compiler provides.
Linux's role is to load the firmware for the program into the PRU's instruction RAM, initialize the resources (e.g. memory, interrupts) for the device, and manage its execution. Meanwhile, Linux can continue doing whatever general-purpose processing it needs to.
Linux and the PRU communicate using interrupts via the remoteproc framework or with messages using rpmsg on top of virtio. Birkett noted that he had often heard kernel developers say that new features should not be added, but that existing facilities should be enhanced, if possible, instead. That is why remoteproc and rpmsg were chosen to be supported for the PRU.
As Birkett noted at the outset, the PRU was mentioned in several other talks throughout the conference. Since Dronecode was one of the themes at ELC this year, and the BeagleBone Black was a common platform for drones, the PRU came up frequently. It frees Linux up to do other tasks, such as computer vision processing, mapping, navigation, video streaming, and the like. Since the realtime needs for drones tend to be small and specialized, offloading them to hardware targeted for that kind of task seems to make a great deal of sense. Other use cases are undoubtedly out there as well.
[I would like to thank the Linux Foundation for travel support to San Jose for ELC.]
Security
Ext4 encryption
For reasons that should be reasonably obvious, there is an increasing level of awareness of the wisdom of encrypting sensitive data stored on devices — especially on devices that, like a phone handset, are easily stolen or lost. In current kernels, encrypting a filesystem requires the use of an add-on module like eCryptfs or dm-crypt. These modules work, but they can have an adverse effect on filesystem performance as a result of the way they are implemented. Performance is important; problems in this area are widely cited as the reason for Google's decision to back off from its plan to encrypt filesystems by default in the Android "Lollipop" release. Linux might be able to provide a filesystem with better performance if encryption were built into the filesystem itself, but, currently, not even Btrfs has encryption as an option.Change is afoot, however; it takes the form of a set of patches adding encryption to the ext4 filesystem. They were posted by ext4 maintainer Ted Ts'o, but the lead developer behind the work is Michael Halcrow — the same developer who added eCryptfs to the kernel ten years ago. The ext4 work, though, reflects some of the lessons that have been learned in the meantime.
Performance suffers in eCryptfs as a result of the stacked nature of the filesystem. Imagine a system running eCryptfs over ext4 now; if a process wants to read a page from an encrypted file, eCryptfs must first instruct ext4 to read that page into the page cache. It then decrypts the data — into another page-cache page. The extra copies of the data can consume a lot of memory and slow things down unnecessarily. Putting encryption support directly into ext4 can eliminate much of that waste.
Encryption in ext4 is a per-directory-tree affair. One starts by setting an encryption policy (using an ioctl() call) for a given directory, which must be empty at the time; that policy includes a master key used for all files and directories stored below the target directory. Each individual file is encrypted with its own key, which is derived from the master key and a per-file random nonce value (which is stored in an extended attribute attached to the file's inode). File names and symbolic links are also encrypted.
The keys used by processes to access the encrypted directory tree are stored in the kernel's keyring as "logon" keys, meaning that user space can create them, but it is not allowed to read the value of the keys. (The kernel's key-management functionality is beyond the scope of this article; see Documentation/security/keys.txt for an overview of how it works). If a user-space process has the requisite master key in its per-process keyring, it can access an encrypted directory as usual. In the absence of the key, though, things are different. Directories can still be read (if the normal permissions and security module policy allow, of course), but the file names will all be encrypted, so the result may not be particularly satisfying. It will be possible to determine how many files are in the directory, their sizes, and their permissions, but not their names or contents. Attempts to open a file (for read or write) without access to the key will simply fail. It is still possible to delete encrypted files, though, if the permissions allow.
If a process with access to the appropriate key reads a page from a file, the filesystem code starts by allocating a separate bounce buffer. The encrypted data is read into the buffer, then decrypted into the page cache. Writes work similarly: the page being written is read from persistent storage and decrypted if necessary; then the new data is written, the data is encrypted into a bounce buffer, and written to permanent storage. Some extra memory is used during the actual encryption and decryption operations, but then it is immediately returned to the system, so overall memory use is significantly reduced relative to eCryptfs or dm-crypt.
Keeping the plain text of an encrypted file in memory has some obvious risks associated with it; if an attacker can get at that memory, all of the work put into encrypting the file on disk is for nothing. To an extent that risk just has to be accepted; the developers are not attempting to make a system that is resistant to attacks when it is hibernated, for example. Still, efforts have been made to clear plain-text data out of memory when it is no longer needed in an attempt to mitigate that risk somewhat. The developers note, though, that if an attacker can make changes to an encrypted filesystem that is subsequently mounted by the user, all bets are off. So ext4 encryption can protect a lost or stolen device, but protecting a device that has been covertly modified is beyond its threat model.
The code currently uses AES-256-XTS as the encryption algorithm for file contents, while AES-256-CBC+CTS is used for file names. The code is designed with the idea that, at some point, it will be desirable to change to a different encryption scheme; care has been taken to avoid wiring the specific algorithm too deeply into the filesystem.
While Google prefers ext4 as the filesystem to use on Android systems, not all Android devices use it. So it is worth noting that Ted has been talking with the maintainer of the F2FS flash-oriented filesystem to get the same ioctl() interfaces implemented there. That would allow Android systems to use encrypted storage on either filesystem without the need for any filesystem-specific code.
This code is marked as experimental in the current patch set, but it may not stay that way for long. There is already user-space code to make use of this feature in the Android open-source repository, and, according to Ted, it will be included in the next major Android release. As of this writing, it has also found its way into linux-next, suggesting that it is intended for the 4.1 merge window. Some developers think that may be premature, though, since the code has just now surfaced. Filesystem changes in general merit a high level of review, given the severe consequences of getting something wrong at that level of the system. Security-relevant code needs even more review, of course. Until that review has happened, developers may well feel nervous about shipping these particular changes in a mainline kernel release.
This obstacle will likely be overcome before too long; at that point Linux will have native encryption support in a major filesystem for the first time. In a period where many people are concerned about the security of their data, that can only be a good thing.
(See this document for some more information on the design of the ext4 encryption mechanism).
Brief items
Security quotes of the week
- How many people have at some point received signed email (S/MIME, PGP, whatever)?
- Of the above, how many people have been warned about some sort of validation failure in said signed email (expired cert, couldn't find the key, signature didn't validate, couldn't find gpg for the validation, etc)?
- Of the above again, how many people immediately deleted the email without looking at it (it could be a drive-by download/infection)?
I would guess that by the time you've got to the third question, you'd be down to zero people (I've been waiting for an excuse to do this poll in a roomful of people at a security conference, just need to get the right talk to ask it at).
Android security state of the union
Google has announced the issuing of a lengthy report [PDF] on the state of Android security. "In 2014, the Android platform made numerous significant improvements in platform security technology, including enabling deployment of full disk encryption, expanding the use of hardware- protected cryptography, and improving the Android application sandbox with an SELinux- based Mandatory Access Control system (MAC). Developers were also provided with improved tools to detect and react to security vulnerabilities, including the nogotofail project and the SecurityProvider. We provided device manufacturers with ongoing support for fixing security vulnerabilities in devices, including development of 79 security patches, and improved the ability to respond to potential vulnerabilities in key areas, such as the updateable WebView in Android 5.0."
Open Crypto Audit gives TrueCrypt a passing grade
At his blog, cryptographer Matt Green announced that the Open Crypto Audit project's review of the now-abandoned TrueCrypt encryption tool is complete, and that "based on this audit, Truecrypt appears to be a relatively well-designed piece of crypto software. The NCC audit found no evidence of deliberate backdoors, or any severe design flaws that will make the software insecure in most instances.
" TrueCrypt was abruptly abandoned by its anonymous developers in 2014, leading some to suspect that a serious vulnerability had been discovered. The final Open Crypto Audit report [PDF] suggests otherwise, which is good news for users as well as for the multiple open-source projects that have subsequently developed TrueCrypt-compatibility support.
Post-Cryptanalysis, TrueCrypt Alternatives Step Forward (Threat Post)
Threat Post takes a look at two TrueCrypt forks, VeraCrypt and CipherShed. Although TrueCrypt development was discontinued last year, the code underwent a two phase audit and passed with a relatively clean bill of health. "VeraCrypt and CipherShed have addressed many of the shortcomings identified not only by the audit, but by others who have scrutinized the TrueCrypt code in recent years. VeraCrypt’s [Mounir] Idrassi, for example, said he replaced TrueCrypt’s lone support of the RIPEMD-160 algorithm with SHA-256 support for system encryption. He said VeraCrypt has also tried to simplify the build process, especially for Linux and Mac OS X systems, so that other less common configurations could be used." The results of the audit of TrueCrypt are available in PDF format; phase 1 was completed in February 2014, and phase 2 was completed March 2015.
Linux Australia server breach
Linux Australia has reported a breach on the Conference Management (Zookeepr) hosting server. This server hosted the conference systems for linux.conf.au 2013, 2014 and 2015, and for PyCon Australia 2013 and 2014. "The database dumps which occurred during the breach include information provided during conference registration - First and Last Names, physical and email addresses, and any phone contact details provided, as well as a hashed version of the user password. As Zookeepr uses a third party credit card payment gateway for credit card processing, the database dumps do not contain any credit card or banking details."
New vulnerabilities
arj: multiple vulnerabilities
| Package(s): | arj | CVE #(s): | CVE-2015-0556 CVE-2015-0557 CVE-2015-2782 | ||||||||||||||||||||||||||||
| Created: | April 7, 2015 | Updated: | December 6, 2016 | ||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
CVE-2015-0556: Jakub Wilk discovered that arj follows symlinks created during unpacking of an arj archive. A remote attacker could use this flaw to perform a directory traversal attack if a user or automated system were tricked into processing a specially crafted arj archive. CVE-2015-0557: Jakub Wilk discovered that arj does not sufficiently protect from directory traversal while unpacking an arj archive containing file paths with multiple leading slashes. A remote attacker could use this flaw to write to arbitrary files if a user or automated system were tricked into processing a specially crafted arj archive. CVE-2015-2782: Jakub Wilk and Guillem Jover discovered a buffer overflow vulnerability in arj. A remote attacker could use this flaw to cause an application crash or, possibly, execute arbitrary code with the privileges of the user running arj. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
chicken: buffer overflow
| Package(s): | chicken | CVE #(s): | |||||||||
| Created: | April 7, 2015 | Updated: | April 8, 2015 | ||||||||
| Description: | From the Red Hat bugzilla:
Buffer overflow vulnerability has been reported in CHICKEN Scheme's substring-index[-ci] procedures. This overrun is only triggered when an integer greater than zero is passed as the optional START argument. As a work-around users are advised to switch to the equivalent string-contains procedure from SRFI 13 which is also shipped with CHICKEN. All releases of CHICKEN up until 4.9.0.1 are affected. | ||||||||||
| Alerts: |
| ||||||||||
chromium: multiple vulnerabilities
| Package(s): | chromium | CVE #(s): | CVE-2015-1233 CVE-2015-1234 | ||||||||||||||||||||||||||||
| Created: | April 2, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||||||||||
| Description: | From the Arch advisory: CVE-2015-1233 (remote code execution): A combination of V8, Gamepad and IPC bugs can lead to remote code execution outside of the sandbox. CVE-2015-1234 (buffer overflow): Buffer overflow via a race condition in GPU. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
drupal7-ctools: multiple vulnerabilities
| Package(s): | drupal7-ctools | CVE #(s): | |||||||||
| Created: | April 3, 2015 | Updated: | April 8, 2015 | ||||||||
| Description: | From the Drupal advisory: Access bypass in autocomplete (Drupal 7 only): Among other many other things, CTools provides an autocomplete callback for finding entities by their titles or ID. In CTools version 1.5, additional checks were created to defend against leaking titles for entities that the user doesn't have access to. However, certain edge cases were found to leak this private data. This vulnerability is mitigated by the fact that you must perform the autocomplete search on custom entities that don't include an access query tag, or you must know the ID of the entity whose title you are trying to get. Open redirect in confirmation pages (Drupal 6 and 7): Also, CTools did not sanitize user provided URLs when processing confirmation delete pages, thereby exposing an open redirect attack vector. This vulnerability is mitigated by the fact that a module using CTools must allow for users to insert a malicious external URL that is sent to the confirmation page. | ||||||||||
| Alerts: |
| ||||||||||
glpi: privilege escalation
| Package(s): | glpi | CVE #(s): | |||||||||||||
| Created: | April 6, 2015 | Updated: | May 12, 2015 | ||||||||||||
| Description: | From the Red Hat bugzilla:
Taking the default account tech, he is only allowed to add users in the following groups: Self-Service, Technician. He has not the right over, for example, the super-admin group. So he cannot add the super-admin privileges to an existing user. The problem is when creating a new user. When intercepting the POST request (GLPI_ROOT/front/user.form.php) of a user creation and modifying the _profiles_id parameter (corresponding to the group attached to the user) to 4, the new user will have the super-admin privileges. | ||||||||||||||
| Alerts: |
| ||||||||||||||
kernel: information leak
| Package(s): | kernel | CVE #(s): | CVE-2015-0777 | ||||||||||||||||||||||||||||
| Created: | April 3, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||||||||||
| Description: | From the SUSE advisory: The XEN usb backend could leak information to the guest system due to copying uninitialized memory. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2015-2672 | ||||
| Created: | April 7, 2015 | Updated: | April 8, 2015 | ||||
| Description: | From the CVE Request:
Jamie and I discovered there was a flaw in the way the xsave/xrstor (and their alternative instructions) were being protected against a fault in kernel space from linux 3.15. The problem was introduced in commit f31a9f7 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") which ends up protecting the .altinstr_replacement from faulting instead of the target of the alternative in .text, leaving the instruction un-protected. | ||||||
| Alerts: |
| ||||||
lasso: denial of service
| Package(s): | lasso | CVE #(s): | CVE-2015-1783 | ||||||||
| Created: | April 6, 2015 | Updated: | April 8, 2015 | ||||||||
| Description: | From the Red Hat bugzilla:
An uninitialized data structure flaw was found in lasso, a library that implements SSO standards. A remote attacker could potentially use this flaw to crash an application using the lasso library. | ||||||||||
| Alerts: |
| ||||||||||
libtasn1: denial of service
| Package(s): | libtasn1 | CVE #(s): | CVE-2015-2806 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 3, 2015 | Updated: | May 12, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch advisory: A two-byte stack overflow has been found in the ASN.1 DER decoding logic of libtasn1. An attacker may be able to crash a program using libtasn1 by submitting a crafted X.509 structure to the program. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
mailman: path traversal attack
| Package(s): | mailman | CVE #(s): | CVE-2015-2775 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 7, 2015 | Updated: | June 24, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
A path traversal vulnerability was discovered in Mailman, the mailing list manager. Installations using a transport script (such as postfix-to-mailman.py) to interface with their MTA instead of static aliases were vulnerable to a path traversal attack. To successfully exploit this, an attacker needs write access on the local file system. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
mingw-qt5-qtbase: denial of service
| Package(s): | mingw-qt5-qtbase | CVE #(s): | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 6, 2015 | Updated: | May 6, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
QtWebKit upstream are reviewing a patch that prevents it recording visited URLs to its favicon database (WebpageIcons.db) while using private browsing mode: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mozilla: certificate verification bypass
| Package(s): | firefox thunderbird seamonkey | CVE #(s): | CVE-2015-0799 | ||||||||||||||||||||||||||||||||||||||||
| Created: | April 6, 2015 | Updated: | September 4, 2015 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
Security researcher Muneaki Nishimura discovered a flaw in the Mozilla's HTTP Alternative Services implementation. If an Alt-Svc header is specified in the HTTP/2 response, SSL certificate verification can be bypassed for the specified alternate server. As a result of this, warnings of invalid SSL certificates will not be displayed and an attacker could potentially impersonate another site through a man-in-the-middle (MTIM), replacing the original certificate with their own. A remote attacker in position of man-in-the-middle can impersonate another site, bypassing certificate validation. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
novnc: VNC session hijacking
| Package(s): | novnc | CVE #(s): | CVE-2013-7436 | ||||||||||||||||||||
| Created: | April 6, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||
| Description: | From the Mageia advisory:
noVNC before 0.5.1 allows an attacker to steal insecurely set session token cookies, hijacking active or inactive VNC sessions. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
ntp: two vulnerabilities
| Package(s): | ntp | CVE #(s): | CVE-2015-1798 CVE-2015-1799 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 8, 2015 | Updated: | April 28, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
CVE-2015-1798 (accept unauthenticated packets): When ntpd is configured to use a symmetric key to authenticate a remote NTP server/peer, it checks if the NTP message authentication code (MAC) in received packets is valid, but not if there actually is any MAC included. Packets without a MAC are accepted as if they had a valid MAC. This allows a MITM attacker to send false packets that are accepted by the client/peer without having to know the symmetric key. The attacker needs to know the transmit timestamp of the client to match it in the forged reply and the false reply needs to reach the client before the genuine reply from the server. The attacker doesn't necessarily need to be relaying the packets between the client and the server. CVE-2015-1799 (denial of service): An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet to host A with source address of B which will set the NTP state variables on A to the values sent by the attacker. Host A will then send on its next poll to B a packet with originate timestamp that doesn't match the transmit timestamp of B and the packet will be dropped. If the attacker does this periodically for both hosts, they won't be able to synchronize to each other. This is a known denial-of-service attack | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
openstack-nova: cross-site websocket hijack attack
| Package(s): | openstack-nova | CVE #(s): | CVE-2015-0259 | ||||||||||||
| Created: | April 8, 2015 | Updated: | April 8, 2015 | ||||||||||||
| Description: | From the Red Hat advisory:
It was discovered that the OpenStack Compute (nova) console websocket did not correctly verify the origin header. An attacker could use this flaw to conduct a cross-site websocket hijack attack. Note that only Compute setups with VNC or SPICE enabled were affected by this flaw. | ||||||||||||||
| Alerts: |
| ||||||||||||||
openstack-packstack: root command execution
| Package(s): | openstack-packstack | CVE #(s): | CVE-2015-1842 | ||||||||||||||||||||
| Created: | April 8, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||
| Description: | From the Red Hat advisory:
It was discovered that the puppet manifests, as provided with the openstack-puppet-modules package, would configure the pcsd daemon with a known default password. If this password was not changed and an attacker was able to gain access to pcsd, they could potentially run shell commands as root. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
owncloud: multiple vulnerabilities
| Package(s): | owncloud | CVE #(s): | CVE-2014-9043 CVE-2014-9045 CVE-2014-9041 CVE-2014-9042 | ||||||||||||||||||||
| Created: | April 2, 2015 | Updated: | April 20, 2015 | ||||||||||||||||||||
| Description: | From the Mandriva advisory: Login bypass when using user_ldap due to unauthenticated binds (CVE-2014-9043) Login bypass when using the external FTP user backend (CVE-2014-9045) CSRF in bookmarks application (CVE-2014-9041) Stored XSS in bookmarks application (CVE-2014-9042) Multiple stored XSS in contacts application (oC-SA-2015-001) Multiple stored XSS in documents application (oC-SA-2015-002) Bypass of file blacklist (oC-SA-2015-004) | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
oxide-qt: code execution
| Package(s): | oxide-qt | CVE #(s): | CVE-2015-1317 | ||||
| Created: | April 7, 2015 | Updated: | April 8, 2015 | ||||
| Description: | From the Ubuntu advisory:
It was discovered that Oxide did not correctly manage the lifetime of BrowserContext, resulting in a potential use-after-free in some circumstances. If a user were tricked in to opening a specially crafted website, an attacker could potentially exploit this to cause a denial of service via application crash or execute arbitrary code with the privileges of the user invoking the program. | ||||||
| Alerts: |
| ||||||
php: code execution
| Package(s): | php, libzip | CVE #(s): | CVE-2015-2787 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 6, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
Use-after-free vulnerability in the process_nested_data function in ext/standard/var_unserializer.re in PHP before 5.4.39, 5.5.x before 5.5.23, and 5.6.x before 5.6.7 allows remote attackers to execute arbitrary code via a crafted unserialize call that leverages use of the unset function within an __wakeup function, a related issue to CVE-2015-0231. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
php5: restriction bypass
| Package(s): | php5 | CVE #(s): | CVE-2015-2348 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 8, 2015 | Updated: | April 8, 2015 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
The move_uploaded_file implementation in ext/standard/basic_FUNCTIONs.c in PHP before 5.4.39, 5.5.x before 5.5.23, and 5.6.x before 5.6.7 truncates a pathNAME upon encountering a x00 character, which allows remote attackers to bypass intended extension restrictions and create files with unexpected NAMEs via a crafted second argument. NOTE: this vulnerability exists because of an incomplete fix for bug CVE-2006-7243. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
potrace: denial of service
| Package(s): | potrace | CVE #(s): | CVE-2013-7437 | ||||||||||||||||
| Created: | April 8, 2015 | Updated: | October 26, 2016 | ||||||||||||||||
| Description: | From the CVE entry:
Multiple integer overflows in potrace 1.11 allow remote attackers to cause a denial of service (crash) via large dimensions in a BMP image, which triggers a buffer overflow. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
quassel: denial of service
| Package(s): | quassel | CVE #(s): | CVE-2015-2778 CVE-2015-2779 | ||||||||||||||||
| Created: | April 8, 2015 | Updated: | August 4, 2015 | ||||||||||||||||
| Description: | From the openSUSE advisory:
* quassel could crash when receiving an overlength CTCP query containing only multibyte characters (bnc#924930 CVE-2015-2778) * quassel could incorrectly split a message in the middle of a multibyte character, leading to DoS (bnc#924933 CVE-2015-2779) | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
subversion: multiple vulnerabilities
| Package(s): | subversion | CVE #(s): | CVE-2015-0202 CVE-2015-0248 CVE-2015-0251 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | April 3, 2015 | Updated: | July 29, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mandriva advisory: Subversion HTTP servers with FSFS repositories are vulnerable to a remotely triggerable excessive memory use with certain REPORT requests (CVE-2015-0202). Subversion mod_dav_svn and svnserve are vulnerable to a remotely triggerable assertion DoS vulnerability for certain requests with dynamically evaluated revision numbers (CVE-2015-0248). Subversion HTTP servers allow spoofing svn:author property values for new revisions (CVE-2015-0251). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
texlive: arbitrary file removal
| Package(s): | texlive | CVE #(s): | CVE-2015-0296 | ||||||||
| Created: | April 3, 2015 | Updated: | April 8, 2015 | ||||||||
| Description: | From the Red Hat bug report: A flaw was found in the pre-install script of texlive-base package derived from texlive package. This flaw allows unprivileged user to remove arbitrary files on the system. | ||||||||||
| Alerts: |
| ||||||||||
tor: denial of service
| Package(s): | tor | CVE #(s): | CVE-2015-2928 CVE-2015-2929 | ||||||||||||||||||||||||||||||||||||
| Created: | April 7, 2015 | Updated: | July 7, 2015 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
CVE-2015-2928: "disgleirio" discovered that a malicious client could trigger an assertion failure in a Tor instance providing a hidden service, thus rendering the service inaccessible. CVE-2015-2929: "DonnchaC" discovered that Tor clients would crash with an assertion failure upon parsing specially crafted hidden service descriptors. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Kernel development
Brief items
Kernel release status
The current development kernel is 4.0-rc7, released on April 6 after a day's delay for the holiday. "But it's still pretty small, and things are on track for 4.0 next weekend. There's a tiny chance that I'll decide to delay 4.0 by a week just because I'm traveling the week after, and I might want to avoid opening the merge window. We'll see how I feel about it next weekend."
Stable updates: none have been released in the last week.
Quote of the week
Kernel development news
Running the kernel in library mode
Once upon a time, the only way to run the Linux kernel was as the primary operating system on a handy piece of hardware. Since then, though, other modes of operation have become possible: the kernel can, for example, be run as the guest of another kernel through virtualization, or as a user-space process with the user-mode Linux (UML) port. One mode that has not been supported is running the kernel as a library that can be called from within an application program, but that situation appears to be about to change thanks to a patch set which has just made its first appearance on the linux-kernel list.This patch set, posted by Hajime Tazaki, goes by the name LibOS; it was presented (slides [slideshare]) at the recent Netdev 0.1 conference. LibOS is structured as if it were a new architecture port; it can be found under arch/lib in the kernel tree. But this port, when built, does not result in a bootable kernel; instead, it creates a shared library that can then be loaded into a running process.
One might wonder why this mode of operation would be useful. Though it is not limited to this particular use, the main focus of LibOS at the moment is to make the Linux network stack available to user-space applications. User-space network stacks are not unheard of in the Linux world; they have shown up in certain performance-sensitive settings for some years now. With LibOS, it is not necessary to write (or port) a new network stack to run in a Linux process; the kernel's network stack is now available to use directly.
Needless to say, one does not just make the network stack callable from user space without doing a bit of work. To make this mode possible, the LibOS developers have created a whole set of stub functions to replace various kernel functions used by the networking code. Indeed, the bulk of the patch set consists of thousands of lines of stub functions. They do things like replacing the slab allocator with a simple version based on malloc() and, for the most part, shorting out the filesystem layer entirely. When that is done, what's left is the networking stack with almost enough scaffolding to let it run standalone within a process's address space.
"Almost enough" because a few tasks are still left to the calling application. For example, there is no stub implementation of schedule(); instead, the calling code must provide one during the initialization process. The idea here is that the running application may want to exert some control over how the management of processes (most likely implemented as POSIX threads) will be done.
There are currently two projects using the LibOS framework. Networking in user space (NUSE) finishes the job of providing a running user-space network stack. With NUSE, one can set up arbitrary networking topologies, interface to other user-space mechanisms like DPDK for fast transmission and reception of packets, and more. The NS-3 system, instead, is a simulation framework used to run tests on network protocols and implementations. It can run network-oriented applications on top of the LibOS network stack using LD_PRELOAD tricks to redirect calls to the networking system calls.
There are a number of interesting things that can be done with these tools. Users running networking in user space for performance reasons could consider using it, though the kernel's stack has not been optimized for performance in that setting. Somebody wanting to run an experimental protocol like MPTCP in production could use LibOS (built with a suitably patched kernel) to get that feature without touching the network stack used by the rest of the system. There are also a lot of opportunities for running debugging tools with a network stack that is running in user mode.
While the LibOS work has been focused on the network stack as the first objective, there is nothing in its design that limits it to networking. If one wanted to, say, isolate the virtual filesystem layer instead, it would mostly be a matter of coming up with the additional stub functions needed.
A question that might come to mind is: how does this differ from the user-mode Linux port that has been in the kernel for many years? Indeed, UML maintainer Richard Weinberger wondered exactly that. There appear to be a few differences. UML is meant to run as a standalone application in its own right, while LibOS runs as a library called by some other application. One can even have several LibOS instances running simultaneously within the same application. Beyond that, the idea of isolating a single subsystem for use within an application is not a part of the design of UML. After looking more deeply at the LibOS code, Richard agreed that it brought some interesting things to the table.
One possible area of concern is the maintenance of all of the stub functions. There are a lot of them, and they will need to be updated whenever the corresponding "real" version is changed in the kernel. Few maintainers are likely to think that they have to update LibOS when they are making changes to their own subsystems. As a result, it seems likely that LibOS will be broken much of the time.
That, in turn, means that maintenance concerns may be one of the chief obstacles LibOS must overcome before it can be considered for merging into the mainline kernel. If LibOS is often broken, developers will hesitate to use it. If LibOS breakage leads to complaints against subsystem maintainers working on their own code, they may respond by calling for its removal. Avoiding these pitfalls may require finding some way to automate the creation of these stub functions. Creating a library-mode version of the kernel may turn out to have been the easy part when one considers what is required to make that work maintainable in the long run.
Write-stream IDs
Storage devices with large physical block sizes — solid-state storage devices (SSDs), for example — are subject to a problem known as "write amplification" that can affect both the performance and lifetime of the device. Applications often have information about the data they write that can be helpful in reducing write amplification problems, but there is currently no way to communicate that information to the relevant parts of the kernel. A new proposed addition to the block-layer API may help to solve that problem in the near future, though.The kernel typically performs block I/O in units of 4KB, but a typical SSD has an erase-block size of many times that. The firmware in the drive itself performs the impedance matching between the small sector size exposed to the host computer and the real requirements imposed by the hardware. Whenever a sector is written, the firmware must find a home for it in a new erase block, leaving an empty space where the sector used to be. Occasionally, sectors must be shifted and coalesced during a garbage-collection pass to free up the empty spaces for new writes.
"Write amplification" refers to this extra work that must be performed when data is overwritten. It gets worse if short-lived data is mixed with long-lived data in the same erase blocks; garbage collection must happen more often and more data must be moved around. On the other hand, if short-lived data can be kept together, the rewriting of erase blocks and garbage-collection work can be minimized. The kernel could perhaps do this kind of separation for some types of filesystem metadata, but it has no knowledge of how user space plans to use the data that it writes to the filesystem. So, if long-lived user-space data is to be separated from the short-lived variety, user space is going to have to help with the job. That is where Jens Axboe's write-stream IDs patch set comes in.
A write-stream ID is simply an eight-bit integer value assigned to block data as it is written. The kernel does not interpret that value in any way other than as a hint that data with the same ID is likely to have approximately the same lifetime. Low-level storage drivers can use this ID to place data with the same life expectancy together on the media, hopefully reducing write-amplification problems in the process.
At the lowest level in the block layer, the stream ID is stored in eight bits of the bi_flags field in the bio structure. It can be set with bio_set_streamid() and queried with bio_get_streamid(). A call to bio_streamid_valid() can be used to determine whether a given bio structure has had its stream ID set; low-level block drivers can use a valid stream ID to instruct the hardware to group similar data on the physical media.
At the user-space level, the stream ID for an open file can be set with the new fadvise(POSIX_FADV_STREAMID) operation. Interestingly, this value is stored in two places: the file structure associated with the given file descriptor, and the inode structure representing the file itself. That might seem like an interesting choice, given that both structures are heavily used and bloating both of them with a new field is not something to be done lightly, but there is a reason for it.
When an application performs direct I/O, the data being written will be placed in a bio structure immediately and passed to the block layer. The file structure corresponding to the file descriptor passed by user space is available then, so the stream ID stored in that file structure can be copied directly into the bio structure.
That option is not available for buffered I/O, though. A buffered write() will simply copy the data into the page cache and mark the relevant page(s) dirty; the actual I/O on those pages will happen at some future time. By the time that the writeback code gets around to those pages, the file structure used to initiate the write may no longer exist. Even if it is still around, though, it is not readily accessible at that level of the kernel. But the inode structure is accessible. So, in this case, the stream ID must be taken from the inode structure.
One might ask why the inode-stored stream ID is not used all of the time. The patches are silent on this point, but the probable answer is that the more direct control afforded by storing the ID in the file structure is worth having when it is possible. It allows the stream ID to be changed from one I/O operation to the next; different file descriptors referring to the same on-disk file can also have different stream IDs. This flexibility is not available when doing buffered I/O and using the stream ID stored in the inode structure; since it's not possible to know when the actual writeback will happen, the stream ID cannot be changed between writes without the likelihood of affecting writes intended to go under a different ID.
There would be clear value in a closer association between stream IDs and specific buffered-write operations. Getting there would require storing the stream ID with each dirtied page, though; that, in turn, almost certainly implies shoehorning the stream ID into the associated page structure. That would not be an easy task; it is not surprising that it is not a part of this patch set. Should the lack of per-buffered-write stream IDs prove to be a serious constraint in the future, somebody will certainly be motivated to try to find a place to store another eight bits in struct page.
Meanwhile, there does not appear to be any real opposition to the patch set in its current form. Unless that situation changes, write-stream IDs would appear to be a feature headed for the mainline in a near-future development cycle.
An update on the freedreno graphics driver
The freedreno project was started by Rob Clark to create a free-software driver for the Adreno family of GPUs, which are used by the Qualcomm Snapdragon system-on-chip (SoC) family. He presented a status report on the project, along with some history and future plans, at the Embedded Linux Conference, which was held in San Jose, CA, March 23-25.
The Adreno 2xx, 3xx, and 4xx are all supported by freedreno. The 2xx GPUs support OpenGL ES 2.0, the 3xx devices support OpenGL ES 3.0 and the embedded profile of OpenCL 1.1, while the Adreno 4xx GPUs support OpenGL ES 3.1 (with the Android Extension Pack) and the full profile of OpenCL 1.2. The 3xx is the first of the modern Adrenos, Clark said, and the 4xx was announced with the Snapdragon 805 SoC, which is the first Adreno to support DirectX 11.
Adrenos have a tile-based renderer, though it is implemented differently than other tile-based devices. Adrenos have a relatively large internal memory for the tile buffer, either in the GPU core itself (GMEM) or elsewhere on the SoC (OCMEM). The driver manages the tile buffers, including handling restore and resolve operations (moving tile data between the CPU and GPU memory). It also handles partitioning the rendering target into tiles. On Adreno 3xx and later GPUs, the driver can decide to bypass the tile buffer to do immediate rendering in certain scenarios.
Motivation and history
Clark got involved because of the lack of free drivers for various Snapdragon-based boards that were becoming available. Graphics progress was being held back because the GPUs were all locked down. These days, developers expect to have GPU acceleration available for user interfaces and other purposes, but for these ARM boards, you were "left with Android or Android" for driver choices. Those drivers didn't come with source, so you couldn't even recompile them. There were some "clever hacks" like libhybris, but "piling on more duct tape doesn't solve the issue".
![[Rob Clark]](https://static.lwn.net/images/2015/elc-clark-sm.jpg "Rob Clark")
So in mid-2012 he decided to do something about it. He was working for TI at the time, so PowerVR-based GPUs (as used by TI) were off-limits. He found some hardware that had an Adreno 220 and started to reverse engineer it. He began work on a Gallium driver in November 2012. By early 2013, he had most of the "normal stuff" working. He could run GNOME Shell and some games on the hardware.
One of the nice things about a Gallium driver, Clark said, is that it supports both desktop graphics and GL ES. Lots of games are not ported to GL ES but can still be played using the Gallium driver.
That early work was done mostly in the evenings and on weekends, but that changed somewhat when he joined the Red Hat graphics team in February 2013. While his freedreno work is not his full-time job, he does get some work time to do freedreno development.
In March 2013, he ordered a Nexus 4, which has an Adreno 320 GPU, and started looking at that. Everything had changed between the two Adreno revisions, including the shader instruction set and the registers. Adreno 2xx support was working well at that point, so it has pretty much been left behind. By mid-2013, he had Adreno 3xx support working at a basic level.
The Direct Rendering Manager (DRM) driver for the MSM (Mobile Station Modem, a Qualcomm hardware designation that is used as the Adreno driver name) devices was merged into the mainline in August 2013 for the 3.12 kernel, which provided a "nice platform" for further development work. In January 2014, he added hardware binning support, which is a pre-pass made on the triangles to be rendered to see which fit in each tile. That sped up rendering so that he was able to get a "fairly playable" 30 frames per second (fps) in Xonotic.
He also started work on a new shader compiler in early 2014. The earlier compiler had just translated TGSI directly to native instructions, but didn't do proper instruction scheduling. Adding that scheduling fixed a number of problems while also giving a big performance boost, he said.
He started work on OpenGL 2.0 and 2.1 support in May 2014. Xonotic supports both OpenGL 1.0 and 2.0, so it can easily be used to test the changes made for 2.0 support.
In perhaps something of a surprise move, Qualcomm posted the first patches for the hardware in June 2014. The initial patches were for display support, but subsequent patches were for the DRM/MSM driver itself. Clark strongly commended Qualcomm for doing that work upstream.
In mid-2014, he got his hands on his first Adreno 4xx device (an Inforce6540 with an Adreno 420). He found that nearly all of the registers had all changed again, which required another round of reverse engineering to figure them out. The shader instruction set was quite similar to that of the 3xx, so he was able to share that code between the two GPU versions.
By October 2014, 90% of the Piglit OpenGL tests were passing for the Adreno 3xx. Piglit is useful to test "weird corner cases", he said. It is often the case that games will work fine, but lots of Piglit tests still fail.
Kernel driver patches to enable the 4xx were submitted by Qualcomm in November 2014 for the 3.19 kernel, which was another big step for the company. The initial Gallium support for the 4xx was also released around the same time. As of February 2015, the 4xx support is behind where the 3xx is, but most games and other programs are largely working at this point. By March 2015, the new shader compiler was able to handle everything that the old compiler could, so the old one has been retired.
The architecture for freedreno is much the same as for the Intel, Radeon, or Nouveau drivers. There are multiple user-space pieces (Gallium driver, X video driver, and libdrm_freedreno) that talk to the kernel driver. By implementing it that way, they got Wayland support for free. GNOME Shell works just fine on Adreno hardware using the Wayland compositor.
Clark said that he doesn't know much about the Android graphics stack. He would like to see Android support free graphics for Adreno devices, but that requires further investigation.
User space
The biggest single component of an open-source graphics driver is the Gallium driver, he said. The freedreno Gallium driver has a common core that handles tasks like dirty state and buffer tracking, tile-buffer management, and fences (i.e. synchronization operations). There are also separate components (fd2, fd3, and fd4) to handle each generation of Adreno devices, as well as a shader compiler (ir3) that is shared between 3xx and 4xx devices.
The user-space piece of freedreno builds up a command stream that has lots of register references. That gets sent to the kernel driver, which is a "glorified register writer", Clark said. The shader compiler is the single largest piece of the user-space driver. He also went into some details of the tiling implementation and how queries (e.g. occlusion queries) are handled by the driver and the hardware.
Turning to debugging, Clark said that the FD_MESA_DEBUG environment variable is the most useful technique for debugging. This command:
$ FD_MESA_DEBUG=help glxinfo
will produce a help message that lists other values for the environment
variable. Another useful tool is apitrace, which will save
all of the GL commands into a trace file. That file can be used to
reproduce some problem entirely separate from the program that produced the
output. Command-stream traces can also be grabbed from the kernel driver
(using the /sys/kernel/debug/dri/0/rd file).
The envytools from the Nouveau project were used to generate header files that describe the Adreno registers for both the Gallium and DRM/MSM kernel driver. As he figures out the registers of the GPUs, Clark enters them into an XML file that is used by other tools, both to create the headers and to decode various kinds of trace files. For example, cffdump can decode the command-stream trace files from both the free and binary blob drivers to compare the output of each. Information about the tools used to reverse engineer the GPUs is available on the freedreno wiki.
GL/GL ES 3.0
There is a lot of work going on "behind the scenes" to enable GL/GL ES 3.0, Clark said. A lot of the work to do so has been done by Ilia Mirkin. Supporting 3.0 will enable more games to work and will provide more advanced rendering features. Clark has also done work on the shader compiler to support the new version of the GLSL shader language.
For GL ES 3.0, the "big ticket item" that is left to do is to implement transform feedback and uniform buffer objects (UBOs). For those, the reverse engineering has been done, all that's left is to "write code". The code for multiple render targets (MRTs) exists on a branch, but has not yet been merged. There is also some shader compiler work to support advanced flow control, but that is not used in games much.
Support for the NV_conditional_render extension is the biggest piece left for GL 3.0 support. Clark said that the extension could be called the "we hate tilers" extension, since handling it will perform badly on a tile-based GPU.
The shader compiler is already the biggest piece of the user-space driver, but it will be getting somewhat bigger to handle some of these new features. Clark has started documenting the compiler design and the Adreno instruction set architecture. He has also has some preliminary work toward supporting the new internal representation (NIR), which is an Intel effort aimed at a new shader compiler IR for better optimization. He has a TGSI to NIR translation patch, but it is not ready to land yet.
Getting the freedreno driver should be easy, since all of the pieces are already upstream. Distributions generally already have it enabled. He recommends Mesa 10.4.x for Adreno 3xx devices and 10.5.1 (or higher) for 4xx GPUs.
As with most free-software projects, freedreno could use some help. To start with, if a distribution doesn't have the driver enabled, help make that happen, he suggested. Bug reports are also welcome. For those interested in actually working on the driver, there is help needed in "everything from the kernel to compilers". For those that know GL/GL ES, adding more tests would be helpful as well.
Clark described the process of reverse engineering a bit in answer to a question from the audience. He will start with a simple GL program that draws a "quad" (a four-sided polygon), then he will change the frame buffer size to see what the blob driver does differently. As he sees different registers and values, he records what he finds in the XML file that is used by cffdump and other tools. He runs a series of tests, just varying one parameter at a time to see what changes and slowly works out all of the registers. For the most part, these tests are rendered off-screen as he doesn't actually care much about what the output looks like.
[I would like to thank the Linux Foundation for travel support to San Jose for ELC.]
Patches and updates
Kernel trees
Core kernel code
Device drivers
Filesystems and block I/O
Memory management
Networking
Miscellaneous
Page editor: Jonathan Corbet
Distributions
Fedora revisits password policies
The Fedora project is revising its stance on forcing users to select strong passwords, mere months after implementing a change that blocked weak-password creation in the Anaconda installer. Testers found the new approach more aggravating than helpful, so the old password-selection criteria will be put back in place for the upcoming Fedora 22 release, and the project will take a hard look at defining a more comprehensive password-security approach for Fedora 23.
As we covered in February, the root of the issue is the concern that, if left to their own devices, users will choose weak passwords that can easily be guessed or cracked. Some coaching about password strength, it was hoped, would push users toward stronger selections. The password chosen while setting up an account with Anaconda, after all, is not used just for desktop logins. A weak choice could expose the system to attack over SSH, and it goes without saying that a weak root password poses an even greater security risk than a weak password for a normal user account.
Thus, setting a higher bar for password strength in Anaconda would have additional benefits down the line. The actual change was made in January by Brian C. Lane. Rather than asking the user to verify their password choice with an additional click (as it used to), the installer would check the password provided and tell the user to choose a stronger one if it failed to meet the minimum length (eight characters) and complexity (assessed by libpwquality).
Even at the time that the Anaconda change was made, though, there were critics who argued that focusing on password strength was a mistake. The real goal is securing the Fedora machine against attack, the critics said, and that ought to involve—and perhaps start with—other steps (disallowing root logins over SSH, allowing only key-based SSH login, and so on). But the change went through nonetheless—it was, at least, quick to implement, whereas rethinking broader security policies would be quite time consuming.
By March, however, Fedora testers had gotten some time to work with
the new Anaconda, and a number of them were not pleased with the
change. A ticket was
opened shortly after Lane's change asking the Fedora Engineering
Steering Committee (FESCo) to "review it and advise the package
developers
". The ticket pointed to a forum
thread where a number of users complained about ill effects of the
change—such as making it more complicated to spin up a new
virtual machine, difficulty in using the new password-checker with
international keyboard layouts, and the general principle of not
forcing behavior on the user.
Furthermore, Adam Williamson from the Fedora QA team commented that users found the libpwquality assessment of their passwords unusually stringent, which may not have been what the Anaconda team had intended. There were also several bugs filed about the new behavior and several mailing-list debates took place. FESCo initially deferred to the Anaconda team's decision, but after continued debate in the ticket comments, it agreed to discuss the matter in its March 4 meeting.
As the log from that meeting notes, FESCo
concluded that it "would like Anaconda to turn back on the
'double-done' option for Fedora 22. Better solutions should be
investigated for Fedora 23.
" Speaking on behalf of FESCo, Adam
Jackson said that the committee
"is prepared to work with Anaconda and other stakeholders to
define security models for the various Fedora products. By clarifying
our needs we hope to avoid this kind of contention in the
future.
"
Reverting the Anaconda change was then designated a Fedora 22 beta blocker. Although the discussion continued, Anaconda's password checker was reverted back to its Fedora 21 behavior on April 4.
Jackson elaborated a bit on the decision in a follow-up email. He would have preferred, he said, for the various teams involved to have found a password-strength level that Anaconda and libpwquality could provide without exasperating users, but that did not happen. As a result, the decision facing FESCo was whether or not the change amounted to a regression from Fedora 21. Kevin Fenzi cited some other, more specific reasons for the decision, such as the fact that Anaconda would tell the user that their chosen password was bad, but would not explain why it was considered bad—nor how to fix it.
Ultimately, though, most participants in the discussion seemed to feel that the ideal solution would be to decide on a real, well-thought-out policy on password strength and security. What such a policy would look like has yet to be decided. Fenzi said that the best outcome would be a policy that encompassed not just Anaconda, but sshd, passwd, sudo, PolicyKit, and perhaps even device mapper and GNOME Keyring as well. Miloslav Trmač agreed, noting in particular that disk encryption warrants serious thought:
A policy encompassing so many factors may take some time to devise. For example, Michael Catanzaro felt that Anaconda should stop doing account creation altogether, and leave that task up to a "first-run" tool. Such a separation of tasks might make the security-policy decision easier to handle, since it would allow the Fedora Server, Cloud, and Workstation product groups to each implement their own policy. Part of the problem with February's Anaconda password-creation change, after all, stemmed from the fact that cloud and desktop systems have a significantly different use case for user accounts.
While the debate on a project-wide password policy may take quite some time to reach a conclusion, work has progressed on changes to allow the different product teams to tune Anaconda's behavior. In March, Lane committed a change that will allow different Fedora products to specify different password-checking behavior in the Kickstart file. That will at least allow some different defaults settings to be deployed for different use cases.
Fenzi has started a draft policy page on the Fedora wiki, although it is largely blank at the moment. The last real attempt at devising any sort project-wide password-security policy was done for Fedora 17, so considerable differences should be expected. As for when the new policy will take shape, it is probably too early to say—the interest is there, but right now the focus is on getting Fedora 22 out the door. Expect to a more concerted effort once that is complete and everyone's attention turns to Fedora 23.
Brief items
Distribution quote of the week
But whatever. Neither Gentoo nor the rest of the world runs on facts or even right and wrong, so carry on. :)
Newsletters and articles of interest
Distribution newsletters
- DistroWatch Weekly, Issue 604 (April 6)
- 5 things in Fedora this week (April 3)
- Ubuntu Weekly Newsletter, Issue 411 (April 5)
Parsix 7 Morphs GNOME Into a Better Desktop (LinuxInsider)
LinuxInsider reviews Parsix 7. "Parsix has been around for several years and has built a reputation for dependability. It offers the very solid stability of Debian, with a hefty mix of desktop performance for both 32-bit and 64-bit systems. The developer community is far more independent than other Debian testing-based derivatives. The Parsix community keeps four software repositories enabled by default. Official repositories contain packages maintained by project developers that are built on the community's own build servers."
Page editor: Rebecca Sobol
Development
What's coming in Git 2.4.0
The Git project recently turned ten years old, and a new stable release, version 2.4.0, is due shortly. While the development cycle leading up to Git 2.4 has focused largely on improving polish, there are a handful of interesting new features worth checking out, plus several changes that users need to be aware of for compatibility reasons.
A "preview" release candidate (-rc0) for Git 2.4.0 arrived on March 26; the first official release candidate (-rc1) followed on April 2. The release notes that accompany both announcements highlight a lengthy list of bugfixes (many of which have also been implemented in the current 2.3.x series) as well as a large set of improvements to the official documentation and to the terminal output returned by individual Git commands.
Some of those output fixes could have genuine impact on a user's workflow, of course. To cite one simple example, in previous releases, providing a non-existent name to the --author= parameter when making a commit would result in a rather terse error message that could leave users wondering what the source of the problem is. The new error message makes it explicit that the --author= parameter is at fault.
Output reporting success was improved, too; for example, the git apply --whitespace=fix command now actually returns a message whenever it fixes white-space problems. The release notes point out, though, that some of the changes to output formatting (in particular with git log and git branch) could result in backward incompatibilities. Users that parse the output from these commands in software will need to update their code.
For most users, though, it is new functionality that will attract the most attention. Topping the list for Git 2.4.0 might be the addition of the --atomic option when doing a push. Not to be confused with "the nuclear option," this switch is actually used when the push in question is meant to update more than one reference (say, HEAD and an important remote reference). Adding --atomic ensures that if any of those updates fails, all of the others will fail, too, thus keeping things from getting out of sync.
A push-to-deploy feature was added in Git 2.3, allowing users to use the push command to deploy changes directly onto a running system. That feature has seen some improvement for 2.4, with the user being able to customize the behavior of the server's repository using the push-to-checkout hook. The example included in the patch's documentation involves a hook that lets the server retain any locally-changed files that do not interfere with the changes being pushed. It is not clear at the moment how many people use Git to deploy software on live servers, but additional flexibility is certainly welcome for those who do.
Among the other tools, there are several new features to point out. An --invert-grep option has been added for the log command. As one would surmise from its name, this allows users to search their logs for commits that do not match a particular pattern. There is also a new GIT_TEST_CHAIN_LINT mechanism for use in test scripts. It allows users to check the syntax of their test scripts, hopefully avoiding those situations where a test is silently skipped because of a syntax error, but the resulting silence is interpreted as a passed test.
The status command already included a -v switch to enable verbose output, but that switch only displays a verbose diff between the index file and the current HEAD. Starting with Git 2.4.0, adding a second -v switch will also show a verbose diff of the uncommitted changes. The archive command can now set the text attribute (which specifies the end-of-line style) on the archive files it generates.
There are also a few new configuration options that may prove interesting. The versionsort.prerelease variable can be used to indicate that version numbers like "1.0-pre1" should come before "1.0." The push.followTags configuration variable makes the --follow-tags option the default for pushes.
The 2.4.0 release does not incorporate a large number of new features, but the significant set of small improvements is a testament to just how active the community remains. Git, even at ten years old, is still adapting to new use cases and the needs of new users.
That process does not appear to be slowing down, either. GitHub just announced a new feature that enables support for large files: audio and video, graphics, and data sets. Dubbed Large File Storage, the open-source extension replaces large files in the Git repository with pointers to external storage. No word yet on whether such a feature will find its way upstream, but considering the pace at which Git development moves now, it would not be a surprise, if enough users find it helpful.
Brief items
Quotes of the week
But porting to Qt 4 was a complete and utter disaster and it took us many years to finally get to a Qt 4-based version of Krita that was ready for users: Krita 2.4, released April 11th, 2012. There were reasons for that beyond the mere porting, of course, including the fact that, like fools, we couldn't resist doing a complete refactoring of the basic KOffice libraries.
Libvpx 1.4.0 available
Libvpx 1.4.0 is now available.
This update to the VP9/WebM video library includes 64-bit ARM support and
"Significant algorithmic improvements to VP9 encoding, support
for YUV 4:2:2 and 4:4:4 colorspaces as well as high bit depth (10 and
12 bit)
". There are also several multithreading improvements;
as the announcement explains: "VP9 decoder now has two multithreaded modes: tile based and frame based. The encoder now enables these by default to help ensure your encoded content will be able to take advantage of these modes.
"
Rust 1.0 beta released
The Rust team at Mozilla Research has announced the first beta release of Rust 1.0. The release notes detail a number of important changes, but the announcement adds some additional noteworthy items. "The Beta release also marks a turning point in our approach to stability. During the alpha cycle, the use of unstable APIs and language features was permitted, but triggered a warning. As of the Beta release, the use of unstable APIs will become an error (unless you are using Nightly builds or building from source).
" A new continuous-integration infrastructure has also been deployed. The final release is currently expected around May 15.
Free pattern making software Valentina 0.3 released (Libre Graphics World)
Libre Graphics World takes a look at the latest
version of the Valentina
free-software pattern-making application. The new features include
undo/redo support, improvements to measuring, support for multiple
measurement units, and automatic layout of patterns for printing. The
article also details several upcoming additions. "As for
2D-to-3D workflow, Valentina already supports basic exporting of
Wavefront OBJ files. Going further is likely to be a challenging, yet
quite rewarding enterprise. Imagine previewing the clothes in
MakeHuman on a model that uses body measurements you made with a tape
measure, or using clothes simulation in Blender.
"
DigiKam 4.9.0 released
Version 4.9.0 of digiKam is now available. A large number of bug fixes are included in this release; the development focus remains porting digiKam to KDE Frameworks 5.
Evergreen 2.8.0 released
A new release of the Evergreen open-source library-management system has been announced. Version 2.8.0 includes a number of improvements to the material-acquisition system, a mechanism for libraries to send out messages to library patrons, enhancements to the billing system and "on hold" functionality, and much more.
BlueZ 5.30 available
Version 5.30 of the BlueZ Linux Bluetooth framework has been released.
"The highlight of this release is the completion of the GATT
D-Bus APIs. We’ve now got both the client and server functionality in
place, however it’s still behind the -E (–experimental) command line
switch.
" Also new in this version is an API for managing
Bluetooth Low Energy "advertising," which allows the BlueZ device to
behave like a Bluetooth peripheral.
Konversation 1.6 released
Konversation, the KDE IRC client, has been updated to version 1.6. This release updates the application for KDE Frameworks 5 and Qt5, though it also breaks integration with the KDE Address Book. On the plus side, high-DPI support is included and the on-screen layout has been refreshed.
GnuTLS 3.4.0 released
Version 3.4.0 of the GnuTLS library has been released. Changes include support for the AES-CCM, AES-CCM-8, and Chacha20-Poly1305 ciphersuites (although the latter two must be enabled explicitly) and support for encrypt-then-authenticate in CBC ciphersuites.
Newsletters and articles
Development newsletters from the past week
- What's cooking in git.git (April 2)
- LLVM Weekly (April 6)
- OCaml Weekly News (April 7)
- OpenStack Community Weekly Newsletter (April 3)
- Perl Weekly (April 6)
- PostgreSQL Weekly News (April 5)
- Python Weekly (April 2)
- Ruby Weekly (April 2)
- This Week in Rust (April 7)
- Tor Weekly News (April 1)
- Wikimedia Tech News (April 6)
10 Years of Git: An Interview with Git Creator Linus Torvalds (Linux.com)
Linux.com talks with Linus Torvalds about the development of Git. "Just to pick an example: the concept of 'merging' was generally considered to be something really quite painful and hard in most SCM's. You'd plan your merges, because they were big deals. That's not acceptable to me, since I commonly do tens of merges a day when in the merge window, and even then, the biggest overhead shouldn't be the merge itself, it should be testing the result. The 'git' part of the merge is just a couple of seconds, it should take me much longer just to write the merge explanation message."
What to Expect When You're Expecting: PHP 7, Part 1 (Engine Yard)
The Engine Yard blog has an introduction to the changes coming in the PHP 7 release. "My personal favorite addition to PHP 7 is the addition of the Combined Comparison Operator, <=>,otherwise known as the spaceship operator. [...] It effectively works like strcmp(), or version_compare(), returning -1 if the left operand is smaller than the right, 0 if they are equal, and 1 if the left is greater than the right. The major difference being that it can be used on any two operands, not just strings, but also integers, floats, arrays, etc."
Page editor: Nathan Willis
Announcements
Brief items
Tor Summer of Privacy
The Tor Project and the Electronic Frontier Foundation (EFF) have announced a mentoring program entitled the "Tor Summer of Privacy" (TorSoP). Akin to the Google Summer of Code, TorSoP will provide financial support and mentorship for a group of students to work on privacy-related free software. Three student positions are available this year; applications will be accepted through April 10. More details (including project ideas) are provided on the TorSoP page.
Mourning Chris Yeoh
From the OpenStack community comes the sad announcement of the passing of Chris Yeoh, a longtime free-software developer. "Chris was humble, helpful and honest. The OpenStack and broader Open Source communities are poorer for his passing." Those with memories of Chris are encouraged to contribute them to a collection being put together for his daughter.
Articles of interest
FSFE Newsletter - April 2015
The Free Software Foundation Europe newsletter for April covers Executive Director Jonas Öberg visits Boston, FSFE supports the Christoph Hellwig GNU GPL enforcement lawsuit, a joint statement on the use of Open Standards in the European Commission, and several other topics.
New Books
Teach Your Kids to Code -- New from No Starch Press
No Starch Press has released "Teach Your Kids to Code" by Bryson Payne.
Calls for Presentations
Call for Presentations for GUADEC 2015
GUADEC is the annual conference of the GNOME community. This year GUADEC will be held in Gothenburg, Sweden from August 7-9. The call for papers deadline is May 3.1st Call For Papers - 22nd Annual Tcl/Tk Conference (Tcl'2015)
Tcl'2015 will take place October 19-23 in Manassas, Virginia. The call for papers closes August 24. "The program committee is asking for papers and presentation proposals from anyone using or developing with Tcl/Tk (and extensions)."
CFP Deadlines: April 9, 2015 to June 8, 2015
The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.
| Deadline | Event Dates | Event | Location |
|---|---|---|---|
| April 14 | April 14 April 15 |
Palmetto Open Source Software Conference | Columbia, SC, USA |
| April 15 | June 12 June 14 |
Southeast Linux Fest | Charlotte, NC, USA |
| April 17 | June 11 June 12 |
infoShare 2015 | Gdańsk, Poland |
| April 28 | July 20 July 26 |
EuroPython 2015 | Bilbao, Spain |
| April 30 | August 7 August 9 |
GNU Tools Cauldron 2015 | Prague, Czech Republic |
| May 1 | August 17 August 19 |
LinuxCon North America | Seattle, WA, USA |
| May 1 | September 10 September 13 |
International Conference on Open Source Software Computing 2015 | Amman, Jordan |
| May 1 | August 19 August 21 |
KVM Forum 2015 | Seattle, WA, USA |
| May 1 | August 19 August 21 |
Linux Plumbers Conference | Seattle, WA, USA |
| May 2 | August 12 August 15 |
Flock | Rochester, New York, USA |
| May 3 | August 7 August 9 |
GUADEC | Gothenburg, Sweden |
| May 3 | May 23 May 24 |
Debian/Ubuntu Community Conference Italia - 2015 | Milan, Italy |
| May 8 | July 31 August 4 |
PyCon Australia 2015 | Brisbane, Australia |
| May 15 | September 28 September 30 |
OpenMP Conference | Aachen, Germany |
| May 17 | September 16 September 18 |
PostgresOpen 2015 | Dallas, TX, USA |
| May 17 | August 13 August 17 |
Chaos Communication Camp 2015 | Mildenberg (Berlin), Germany |
| May 23 | August 22 August 23 |
Free and Open Source Software Conference | Sankt Augustin, Germany |
| May 23 | May 23 May 25 |
Wikimedia/MediaWiki European Hackathon | Lyon, France |
| May 31 | October 2 October 4 |
PyCon India 2015 | Bangalore, India |
| June 1 | November 18 November 22 |
Build Stuff 2015 | Vilnius, Lithuania |
| June 1 | July 3 July 5 |
SteelCon | Sheffield, UK |
| June 5 | August 20 August 21 |
Linux Security Summit 2015 | Seattle, WA, USA |
| June 6 | September 29 September 30 |
Open Source Backup Conference 2015 | Cologne, Germany |
If the CFP deadline for your event does not appear here, please tell us about it.
Upcoming Events
ownCloud Contributor Conference 2015
The ownCloud Contributor Conference will take place August 28-September 3 in Berlin, Germany. Registration is open. "Anybody interested in contributing to and improving ownCloud, be it through coding, design, testing, documentation or translating should absolutely join us. Implementing creative, unique ideas or just fixing that annoying problem – that is how ownCloud got where it is and that is how we move forward."
Events: April 9, 2015 to June 8, 2015
The following event listing is taken from the LWN.net Calendar.
| Date(s) | Event | Location |
|---|---|---|
| April 9 April 12 |
Linux Audio Conference | Mainz, Germany |
| April 10 April 12 |
PyCon North America 2015 | Montreal, Canada |
| April 11 April 12 |
Lyon mini-DebConf 2015 | Lyon, France |
| April 13 April 17 |
SEA Conference | Boulder, CO, USA |
| April 13 April 17 |
ApacheCon North America | Austin, TX, USA |
| April 13 April 14 |
AdaCamp Montreal | Montreal, Quebec, Canada |
| April 13 April 14 |
2015 European LLVM Conference | London, UK |
| April 14 April 15 |
Palmetto Open Source Software Conference | Columbia, SC, USA |
| April 16 April 17 |
Global Conference on Cyberspace | The Hague, Netherlands |
| April 17 April 19 |
Dni Wolnego Oprogramowania / The Open Source Days | Bielsko-Biała, Poland |
| April 21 | pgDay Paris | Paris, France |
| April 21 April 23 |
Open Source Data Center Conference | Berlin, Germany |
| April 23 | Open Source Day | Warsaw, Poland |
| April 24 | Puppet Camp Berlin 2015 | Berlin, Germany |
| April 24 April 25 |
Grazer Linuxtage | Graz, Austria |
| April 25 April 26 |
LinuxFest Northwest | Bellingham, WA, USA |
| April 29 May 2 |
Libre Graphics Meeting 2015 | Toronto, Canada |
| May 1 May 4 |
openSUSE Conference | The Hague, Netherlands |
| May 2 May 3 |
Kolab Summit 2015 | The Hague, Netherlands |
| May 4 May 5 |
CoreOS Fest | San Francisco, CA, USA |
| May 6 May 8 |
German Perl Workshop 2015 | Dresden, Germany |
| May 7 May 9 |
Linuxwochen Wien 2015 | Wien, Austria |
| May 8 May 10 |
Open Source Developers' Conference Nordic | Oslo, Norway |
| May 12 May 13 |
PyCon Sweden 2015 | Stockholm, Sweden |
| May 12 May 14 |
Protocols Plugfest Europe 2015 | Zaragoza, Spain |
| May 13 May 15 |
GeeCON 2015 | Cracow, Poland |
| May 14 May 15 |
SREcon15 Europe | Dublin, Ireland |
| May 16 May 17 |
11th Intl. Conf. on Open Source Systems | Florence, Italy |
| May 16 May 17 |
MiniDebConf Bucharest 2015 | Bucharest, Romania |
| May 18 May 22 |
OpenStack Summit | Vancouver, BC, Canada |
| May 18 May 20 |
Croatian Linux User Conference | Zagreb, Croatia |
| May 19 May 21 |
SAMBA eXPerience 2015 | Goettingen, Germany |
| May 20 May 22 |
SciPy Latin America 2015 | Posadas, Misiones, Argentina |
| May 21 May 22 |
ScilabTEC 2015 | Paris, France |
| May 23 May 24 |
Debian/Ubuntu Community Conference Italia - 2015 | Milan, Italy |
| May 23 May 25 |
Wikimedia/MediaWiki European Hackathon | Lyon, France |
| May 30 May 31 |
Linuxwochen Linz 2015 | Linz, Austria |
| June 1 June 2 |
Automotive Linux Summit | Tokyo, Japan |
| June 3 June 5 |
LinuxCon Japan | Tokyo, Japan |
| June 3 June 6 |
Latin American Akademy | Salvador, Brazil |
| June 5 June 7 |
PyCon APAC 2015 | Taipei, Taiwan |
If your event does not appear here, please tell us about it.
Page editor: Rebecca Sobol