Untangling character sets and Unicode blocks

At TypeCon 2016 in Seattle, font engineer Richard Fink kicked off the conference program with a talk entitled "Empty Space Characters In Modern Character Sets" that was, ostensibly, a look at the over two dozen space characters defined in Unicode. But that topic was merely a pretext, leading into a broader examination of how the Unicode character blocks fail to align with languages and writing systems, which makes it difficult to define "language support" in a meaningful way.

Space team

There are, as Fink said, a lot of code points defined in Unicode that amount to some form of white space. But some of them behave differently than others—such as the regular space versus the non-breaking space. And some of them have important semantic distinctions for certain writing systems or scripts, such as the zero-width joiner versus the zero-width non-joiner, which (in connected scripts like Arabic) tell the text rendering engine which variants of two adjacent letters should be used.

There are also quite a few other space characters that differ only in their width. Fink got into the type world to do high-quality web design, he said, and he soon realized that most fonts on the market left out these space characters, which made it impossible to make fine-grained adjustments to complicated layouts by inserting, say, a hair space (code point U+200A) or a medium mathematical space (U+205F).

That was rather frustrating to discover, since all of the necessary glyph slots in the font table could easily be automatically generated. Some time later, Fink worked on the font subset-generator tool on FontSquirrel, which lets users select the sets of glyphs they want for a font and build a minimal font file containing just the glyphs of interest. He did, at that point, add a feature that would automatically generate the missing space characters.

But the encounter prompted him to look more closely at the peculiarities of Unicode. Most of the white space characters, he said, are defined in the "General Punctuation" block, which hardly makes sense, since empty space is not punctuation. Then again, the names of the other Unicode blocks are just as obtuse, featuring, for example, the ambiguous distinction between "Latin Extended" and "Latin Supplement."

That ambiguity makes it hard for two people (or two programs) to agree on what it means for a font to "support" Latin, Cyrillic, Devanagari, or any other writing system. It is even more ambiguous to define what characters are required to support a specific language. And whenever a font does not support the characters that need to appear on screen, the user gets garbled text, either "tofu" (an assortment of box symbols ), question marks, or mojibake gibberish.

Software vendors and font buyers alike would prefer to know whether or not a font support the right glyphs before they start using it. Fink recently started working with the Google Fonts project, and set his mind to finding a definitive set of standards the project could use to validate which fonts supported which scripts and languages.

Character sets

The first alleged solution in the type industry is to look outside of Unicode at character sets, which software companies have historically used to establish their own definitions of what it means to support a language or a writing system. Microsoft had one called Windows-1252 to define basic Latin-alphabet support; Apple had MacRoman, Adobe had Adobe Latin 1 through Adobe Latin 5.

But none of these character sets are an official standard; the proprietary OS vendors created their own as a matter of course because they were competitors. Those character sets are also quite old at this point and are not regarded as particularly relevant. In practice, the main alternative is Adobe's character sets, which often get used and referred to by third parties. But Adobe's sets change, seemingly without warning. Fink said that he has found multiple, conflicting versions of the Adobe character sets published as reference material in a variety of places online.

The trouble is that Adobe maintains the lists for use by its designers and developers, updating them when it needs to. But Adobe has started hosting its character-set definitions in a public repository on GitHub, so Fink got in touch with some current and former members of the type team. However, they made it clear, he said, that Adobe is not interested in maintaining the character sets as a standard or specification, either. Officially, the lists are for internal usage only and the company wants the flexibility to alter them at any time. It was not even interested in version-numbering the updates to the lists, although Fink noted that changes could be referenced by Git commits.

Adding to the trouble is the fact that Microsoft, Apple, and Adobe are all US-based companies, Fink noted, and with that comes an English-centric mindset. Languages and scripts that are "foreign" to Americans get short-changed, and the relevant character sets are more likely to contain omissions or errors. And, again, the naming of the character sets left something to be desired. "'Latin 1'? Why would I care about that; I don't do any work for the Roman Catholic Church," he observed.

Design perspective

The other tactic Fink pursued was to ask type designers what they used as their guide for implementing language support. In February 2016, he posed that question on the TypeDrawers discussion forum. He received scores of replies, but the only take away, he said, was "nobody really agrees on anything." But he did learn that type designers grapple with the same problem from a marketing angle; it is hard to advertise a font based on its Unicode-block coverage, after all.

Thus, Fink eventually decided that it was time to sit down and think about defining new character sets—and, hopefully, to define character sets without a strong US-bias. "I'm unhappy with the term 'multi-script'," which is historically used to describe fonts that offer broad language support, he noted. "Because the word 'script' has too many other definitions, particularly on the web. So I prefer 'trans-national' character sets."

Work on the character-set project is being done in the Google Fonts GitHub repository. So far, the Latin sets are defined in four cumulative levels: Core, Plus, Pro, and Expert, with each intended to enable support for a specific set of languages or use-cases. There is also a group of Cyrillic character sets (Core, Plus, Pro, and Historical); discussions are underway for other languages and the process is open to outside contributors.

Each set pulls from a variety of Unicode blocks, including utility glyphs like arrows and geometric shapes in addition to alphanumeric characters. Notably, they also include several glyphs that do not map to separate Unicode code points, such as small capitals, certain ligatures, and small numerals for scientific subscripts and superscripts. As one would expect, the space characters are included. The character sets also suggest a standardized naming scheme for the glyphs within a font's internal tables, although those names are not generally exposed to end users.

Defining support by language (rather than by script) was one of the better decisions made in the development of the FontSquirrel subset-generator, Fink said. It maps better to what the average user thinks of when evaluating the capabilities of a font. In addition, Fink noted that Dutch Type Library's OTMaster program, "without which I don't know if my life would be livable," also considers language support to be the feature of interest.

Fink ended the talk by observing that applications have some catching up to do where non-standard glyphs are concerned. Adobe InDesign is the only application he has found that even allows the user to select and insert the Unicode space characters. Web applications are underpowered in this respect, too, he said. As of HTML 5.0, all of the space characters have a named HTML character entity reference (apart from the ability to enter a character by its Unicode code point, that is). While HTML 4 supported 252 named entities, HTML 5 defines more than more than 2,000, and all major browsers understand them. It remains up to developers to make use of that feature.

Comments (39 posted)

What's next for Apache OpenOffice

The current chair of the AOO project management committee (PMC) is Dennis Hamilton, whose term is set to end shortly. He has been concerned about the sustainability of the project for some time (see this message from one year ago, for example), a concern sharpened by the routine requirement that he report to the Apache Software Foundation (ASF) board on the project's status. The board, seemingly, had asked few questions about the status of AOO until recently, when the handling of CVE-2016-1513 (or the lack thereof) came to its attention. Now the board is apparently asking some sharp questions indeed and requiring monthly (rather than every three months as usual) reports from the project. "Retirement" of the project, it seems, has been explicitly mentioned as a possibility.

Pondering retirement

In response, on September 1, Hamilton went to the AOO development list with a detailed description of what retiring the project would involve. He said:

Given that, he said, it is time to openly face the prospect that AOO is not sustainable and needs to be wound down. ASF board member (and corporate vice president) Jim Jagielski added that "it has become obvious to the board that AOO has not been a healthy project for some time." Given that, he said, the important thing is to figure out what is to be done now.

This conversation has been widely reported; the result, unsurprisingly, has been a strong "we told you so" response. There has been quite a bit of rehashing of the history of the AOO project and how the current situation came to be. But Jagielski had a point when he said that most of that does not matter; what does matter is what happens next. Your editor would agree. There may be an opportunity to make things better for developers and users of free office suites, but doing so may require forgiving and forgetting quite a bit of unpleasant history.

Jagielski suggested that, while the project cannot sustain itself as an end-user-focused effort, it may be able to go forward as a framework that others could build applications with. Who those others would be was not specified. He suggested that the OpenOffice.org domain could be redirected to LibreOffice — a suggestion that still seems to be seen as heretical by many in the AOO project.

To top things off, he even said that the project might consider making an apology of sorts for the excesses of one of its advocates in the past. While his tone might be read as being less than fully sincere, one would hope that any such apology, should it be forthcoming, would be taken at its word and accepted fully. LibreOffice developers could even consider making an apology of their own (they have not been 100% perfect either), perhaps ahead of anything from AOO. The sharing of some conciliatory words could do a lot to end the hostilities of past years, enable cooperation, and bring about a solution that is good for everybody involved.

Pondering non-retirement

The above discussion, like much of the conversation on the net as a whole, has an underlying assumption that AOO will, indeed, wind down. The project has been unable to compete with LibreOffice; its commit volume and developer participation are not just lower, they are two orders of magnitude lower. LibreOffice makes regular feature and maintenance releases; AOO has been unable to put out even a single emergency security-fix release. LibreOffice has significant corporate investment driving its development; AOO, seemingly, has none since IBM ceased its involvement. The current AOO development community is too small to even hope to fully understand its (large) code base, much less make significant improvements to it. So, to many, it seems clear that AOO is not sustainable.

There are, however, AOO developers who disagree with this assessment. Some of them clearly think that AOO can be saved and saw Hamilton's message as something close to an act of sabotage. Others saw it as "liberating" and as a way to kickstart the process of bringing in new developers. AOO's remaining community has a clear attachment to the project and a strong lack of desire for any kind of accommodation with LibreOffice. It was said by a few that AOO provides an important competition for LibreOffice, though what form that competition takes when the project has not made a feature release for 2.5 years is not clear.

What is clear is that AOO needs to bring in more developers if it is going to survive. To that end, a new recruitment mailing list has been created to help new developers get started. Plans are forming to try to turn the current round of publicity into a call for developers to join a reinvigorated AOO project. Jagielski has claimed that "AOO has simply been overloaded w/ emails from developers and other contributors offering their help, skills, talents and support" since the discussion started, but that overload is not yet evident on the mailing lists.

The developers involved must surely be aware of just how big a challenge they face. Many office-suite users may not have heard of LibreOffice, but the development community is well aware of the relative health of the two projects; attracting them will continue to be hard. The state of the code base, which has not seen the sort of energy put in by LibreOffice to make development easier, will not help. There is no financial investment going into AOO and, seemingly, no plans to try to attract any; if a company did come in, it would likely end up dominating the project in short order — a situation with its own problems.

AOO also has an interesting problem that is not shared by many other projects: it is subject to the decisions of a foundation board of directors that is concerned about potential damage to the overall Apache brand. Even if the AOO developers feel they are making progress, the possibility of the board pulling the plug on them is real. As board member Greg Stein recently said, "PMCs do *not* want the Board involved ... it rarely turns out well for them". Should such a thing happen to AOO, its developers would still have the source, of course, but would lose access to the ASF's resources and, probably, the OpenOffice brand. With such a cloud hovering over them, it is not surprising that AOO developers are concerned and asking for more time.

So the challenge is real. But one thing should be kept in mind here: the free-software community is famous for proceeding in the face of "you can't possibly accomplish that" criticism and proving the critics wrong. A quick look back at what was said about the GNU project in the 1980s, or Linux in the early 1990s, will drive that lesson home. One should never underestimate what a small group of determined developers can do. If the AOO developers think they can muster the resources to manage their code base, they should probably be given the space — by the ASF board and the world as a whole — to try.

The board, though, would be right to want some specific milestones to demonstrate that the project is back in good health and able to meet its users' needs. Apache OpenOffice cannot continue to distribute software that it cannot fix and cannot keep secure, using a well-known trademark to keep up a user base that may be unaware that there is little underneath. One way or another, that is a situation that needs to be fixed.

It is rare for the community to talk overtly about shutting down a project; usually, projects either just fade away or they are killed by a parent company with little warning. It is the type of discussion that we naturally tend to shy away from. But, like people, projects have a life cycle and do not last forever. Facing up to that cycle can motivate developers to rejuvenate a project or, at worst, can help minimize the pain caused by a shutdown. The AOO project has thus begun an important conversation; quite a bit rides on how it ends.

Comments (146 posted)

Toward measured boot out of the box

Matthew Garrett began his Linux Security Summit talk by noting that the "security of the boot chain is vital" to having secure systems. It does not matter if the kernel can protect itself, referring to the talk just prior to his; if the boot process can be manipulated, those protections are immaterial. So, he wanted to present where things stand with regard to securing the boot chain.

In the Linux world, UEFI Secure Boot is the primary boot protection mechanism; it requires that the bootloader be signed by a key that is trusted by the firmware or the system won't boot. There are also various solutions for embedded devices that are typically implemented by the system on chip (SoC). The trust is rooted in the firmware in either case; if someone can modify the firmware, all bets are off.

Beyond that, most of the existing mechanisms provide no way to prove that the verification of the code to be booted has been done. The running kernel has no way to know that it is running on a base that has been integrity checked—or even whether the kernel itself has been tampered with—any query it could make could be answered with a fake "yes".

That kind of attack generally requires privileged access to the hardware, which is a hazard in its own right, so why would those kinds of attacks matter, he asked. One problem area is that there are providers of "bare metal" servers for users who want the convenience of the cloud without its usual performance penalty. Users of those systems will have root privileges, which will allow them to access the hardware, including potentially permanently changing the firmware to something malicious.

He posited a scenario where an attacker would take out a large number of short-term leases on hardware at a site that is known to be used by the victim. Each system is then infected with malicious firmware and "returned" to the pool at the hosting company. Some of those systems will eventually be picked up by the victim; "Secure Boot will not help you" in that situation, he said.

Another worrisome possibility is for laptops that are surrendered when passing through borders. Perhaps it is overly paranoid to be worried about permanent firmware changes being made at the border, he said, but it is at least worth thinking about. While there is not much that can be done to protect against hardware-based attacks (e.g. adding some malicious hardware to a laptop or server), most of the other kinds of attacks can be handled.

TPM to the rescue

The Trusted Platform Module (TPM) is a bit of hardware that can help. When it was first introduced it got a bad reputation because it was "easy to portray it as a DRM mechanism", though it is difficult to deploy that way and no one has actually done so. TPMs are small chips, made by several different manufacturers, that are generally differentiated by their performance and amount of NVRAM storage they provide. TPM implementations also have "a bewildering array of different bugs", Garrett said.

TPMs have several functions, but the one of interest for ensuring that the boot process has not been tampered with uses the platform configuration registers (PCRs). They are normally 16-24 registers that are not directly accessible outside of the chip; all access is mediated by the rules of the TPM. PCRs are 20 bytes long in TPM 1.2, which is the length of an SHA-1 hash; TPM 2.0 allows for multiple hash algorithms, so the number and size of the PCRs changes to support them.

Ensuring tamper-free boot means that each step of the process must be "measured", which effectively means calculating a cryptographic hash of the binary. Each step in the boot process would measure the next, so the firmware measures the bootloader, the bootloader measures the kernel and initial ramdisk (initrd), and so on. The PCRs provide a tamper-proof mechanism to assist in the measurement process.

One cannot store a value directly into a PCR; instead the TPM must be asked to store the value, which it does in a way that provides integrity to the result. Instead of just storing the value, which would allow any program with access to the hardware to set it to the "right" value, it concatenates the existing value in the PCR and the written value (typically the hash of the measured data) and hashes the result. So, in order to reproduce the value in a given PCR, the same measurements must be written to the register in the same order.

There is also a log associated with the TPM. Each measurement adds an entry to the log that records what was measured and what the hash was. While untrusted code can overwrite the log, he said, that turns out not to be as much of a problem as it sounds.

All x86 firmware has measurement capabilities, though sometimes there are problems with what they can measure. For example, there was firmware he encountered that would measure code that came from disk, but not code that came via a network boot, which kind of misses the point. But that firmware has since been fixed.

Bootloader support

There is no Linux bootloader that supports measurement, however. At one time, TrustedGRUB could be used, but it is now "old and busted"; it worked, but it "wasn't particularly nice", Garrett said. Rohde & Schwarz Cybersecurity have developed TrustedGRUB2, which supports using the TPM, but it has some shortcomings. In particular, it does not support UEFI or TPM 2.0. So, Garrett and others have added code to GRUB 2 to support measuring the kernel and other components at boot time (in this GitHub repository).

There is more to measure than just the kernel, however. The booted state of the system is affected by many other components and configuration files. The kernel command line is relevant, as is the GRUB configuration, since GRUB has a scripting interface that can make hardware changes.

But putting each individual configuration piece into its own PCR does not scale because there are a limited number of them. So there is a need to reuse PCRs, but the final value of the PCR will depend on the order in which those items were measured. Trying to establish a strict ordering is something he would like to avoid. There is also the problem that unimportant changes to configuration files (e.g. comments) will still cause the final hash value to be different. For those and other reasons, using the PCRs that way is suboptimal, he said.

Instead, though, the log file can be used. It can be overwritten with invalid data, but that can be detected by replaying the log and calculating the hashes independently. There are two formatting possibilities for the log messages that Garrett described. The first would log a description of the binary and its hash, which is fine for a small number of binaries. That doesn't work so well for configuration information, though, because it may have unimportant changes that alter the hash. For those, the log entry would contain the text that has been hashed in conjunction with its hash.

Then there needs to be a policy file that describes the acceptable hashes for binaries as well as the allowable text for configuration (using regular expressions for parameters and the like). Creating that policy may be rather troublesome, though. His employer, CoreOS, builds the policy automatically for each release. The policy is not complete, however, since it needs known-good hashes for the firmware on the system and no firmware vendor he knows provides that information. So CoreOS users must extract the values from a known-good system, which will work fine unless the firmware is upgraded at some point.

While it is easy for CoreOS to provide an initial RAM filesystem (initramfs) and its hash, other distributions build the initramfs on the user's system when the kernel or other components are updated. Timestamps then get into the binary, which means the hash is different for each. Some kind of generic initramfs using reproducible build mechanisms would alleviate that problem.

There is also a question of where the boot data gets stored. If it is stored in the initramfs, that will change the hash, so he suggested using UEFI variables for some information and the TPM for keys. In a process known as "sealing", the TPM can store encrypted information that it will only decrypt if certain PCRs have the right values to show that the boot process has not been tampered with. Having sealed keys for tpmtotp (Time-based one-time password, TOTP, attestation using the TPM), disk encryption, or SSH would ensure that the data is only available to properly booted systems.

One problem that has not yet been solved is handling firmware or operating system upgrades. There needs to be a mechanism to unseal values and reseal them based on the upgraded system. So far, no solution to that problem has been found.

Intel's Trusted Execution Technology (TXT) is supposed to make this all easier, he said, but that isn't the case. TXT is based on a dynamic root of trust, rather than the static root of trust used by TPM, which in theory would sidestep some of the problems that the TPM-based boot integrity has encountered. But TXT has "no meaningful support for Secure Boot" and it is also incompatible with runtime UEFI. In effect, Garrett said, TXT is not compatible with the way we boot operating systems.

To do

There are still things that need to be done before this gets into the hands of users. Support for it needs to ship in bootloaders; the firmware in desktop systems is likely to have lots of different bugs that may cause systems using this feature not to boot, so there is a lot of testing work to be done there. Firmware vendors and distributions will need to start shipping known-good measurements. The firmware upgrade process will need to be integrated with updating the measurement information and there will need to be ways to create initramfs images deterministically. But we are getting closer to having measured boot right out of the box.

One audience member wondered about the patches to GRUB 2 and whether those would be making their way upstream. Garrett said that he plans to do that; he has talked to Richard Stallman and convinced him that what was being done was "not intrinsically evil", which was met with audience applause. Garrett joked that he hoped that would find its way into his annual performance review.

GRUB 2 has a new maintainer who is more active, he said, which should help getting this work upstream. There is one problem, however, in that the GRUB 2 project requires copyright assignment and some of the code comes from TrustedGRUB, which he can't assign. He is looking to resolve that since he does not want out-of-tree patches.

[I would like to thank the Linux Foundation for travel support to attend the Linux Security Summit in Toronto.]

Comments (11 posted)

AMD memory encryption technologies

Today's virtual machines (VMs) have a variety of protections from their brethren, but hypervisor or kernel bugs can allows guests to access the memory of other guests. In addition, providers of VMs can see the memory of any of the guests, so users of public clouds have to place a lot of trust in their provider. AMD has some upcoming features in its x86 processors that will encrypt memory in ways that alleviate some of these problems. David Kaplan gave a presentation about these new technologies at the Linux Security Summit in Toronto.

The motivation for these features is the cloud environment. Currently, the hypervisor must enforce the isolation between guests through a variety of means: hardware virtualization support, page tables, VM intercepts, and so on. But sometimes those break down, leading to various vulnerabilities that allow guests to access other guests, which is scary, he said.

But users are required to trust their cloud providers since they have full access to all guest memory to extract secrets or even to inject code into VMs. The cloud providers would rather not have that power, Kaplan said; they do not want to be able to see their customers' data. For one thing, that protects the providers from "rogue admin" attacks, where a disgruntled employee uses the unwanted access to attack a customer.

That kind of attack, as well as those where a guest gets access to another guest's memory, are "user-access attacks", he said. AMD is targeting those as well as "physical-access attacks", where someone with access to the hardware can probe the physical DRAM interface or freeze and steal the memory chips (e.g. a cold boot attack). How important it is to resist those and other, similar attacks depends on who you talk to, he said.

There are two separate features—Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)—that both use the same hardware support that will be provided in upcoming processors. That support includes an AES-128 hardware engine inline with the RAM and memory controller so that memory can be encrypted and decrypted on the way in and out of the processor with "minimal performance impact". The data inside the processor (e.g. registers, caches) will be in the clear; there will just be a "little extra latency" when RAM is involved.

All of the keys will be managed within the SoC by the AMD Secure Processor, which is a separate 32-bit ARM Cortex A5 that is present on recent SoCs. It runs a secure (closed source) operating system and enables hardware-validated boot. It is used in some laptops as a firmware Trusted Platform Module (TPM). The secure processor will only run AMD-signed code; it also provides cryptographic key generation and management functions.

Of the two features, SME is the simplest. It uses a single key that is generated at boot time using the random-number generator to transparently encrypt pages that have been marked with a special "encrypted" bit in the page-table entry. The operating system or hypervisor manages which pages will be encrypted in RAM by use of that bit. There is support for hardware devices to DMA to and from encrypted memory as well. SME is targeted at thwarting physical-access attacks, since the contents of memory will be inaccessible without the key that is not accessible outside of the secure processor.

SEV, on the other hand, is more complicated. It has multiple encryption keys in the design and is meant to protect guests' memory from each other and from the hypervisor. The eventual goal, Kaplan said, is for the hypervisor to have no view into the guest.

There are keys for the hypervisor and for each VM, though groups of VMs could share keys and some VMs might be unsecured. SEV cryptographically isolates the guests and hypervisor to the point where cache lines (which are unencrypted) are tagged with an ID that specifies which address space they belong to; the processor will prevent guests from accessing the cache of other guests.

The owner of a guest is a "key player" in using SEV, Kaplan said. Information like secrets and policies will need to be transferred to the secure processor using the hypervisor to transport that data. Since the hypervisor is untrusted in this model (so that cloud providers do not have access to customer secrets), the guest owner will create a secure channel to the secure processor (through the hypervisor) using Diffie-Hellman (DH) key exchange.

Launching a guest is a somewhat complicated process; Kaplan's slides [PDF] may be of interest for those who want more details. The hypervisor begins by loading an unencrypted BIOS or OS image into memory. The guest owner then supplies their DH key and the hypervisor facilitates the creation of a secure channel between the guest owner and the secure processor (without being able to eavesdrop on the traffic). Part of that exchange will provide the guest owner with a certificate that allows them to prove that they are truly talking to the secure processor.

The hypervisor then allocates an "address space identifier" (ASID), which is what identifies the guest (and the key for that guest's memory). That ASID is provided to the secure processor with a request to generate or load a key into the AES engine and to encrypt the BIOS/OS image using that key. The hypervisor then sets up and runs the guest using the ASID assigned; the memory controller, AES engine, and secure processor will work together to ensure that the memory is encrypted and decrypted appropriately.

The hypervisor will also send a "launch receipt" to the user that includes a measurement (hash) of the image and some platform authentication information. If the user is provided with the right measurement, they can then provide secrets like disk encryption keys to the guest over a secure channel (e.g. TLS).

There are two levels of page tables: one for the guest and one for the hypervisor. The guest tables determine whether the memory is private or is shared with the hypervisor. All executable pages are private (no matter the setting), as are the guest's page tables. Data pages can be either, but DMA must use shared pages.

A common question that is asked is in regards to the ASID: couldn't the hypervisor "spoof" a different ASID? The answer is that it could, but it wouldn't really gain it anything. If it tries walking the guest page tables or executing code using the wrong key, it will not be particularly successful. SEV is meant to block a range of attacks, both physical and user access; the intent is to reduce the attack surface even more in coming years.

In order to use SEV, both hypervisors and guests will need to change to support it. There are a number of software components required, some that AMD expects to ship and others that it is working with the open-source community on. The secure processor firmware is distributed in binary form and the source is not public. There is a Linux driver to support the secure processor that has been posted for review. The open-source hypervisor support is also being worked on.

There was a question about why AMD had not used the TPM API for its secure processor. Kaplan said there was interest in a simpler API that focused on the VM launch cycle. But the API is available and is only in beta at this point, so those interested should comment. Also, as is often the case with processor features, Kaplan was unable to say when SoCs with either feature would be available.

[I would like to thank the Linux Foundation for travel support to attend the Linux Security Summit in Toronto.]

Comments (22 posted)

Security quotes of the week

Comments (8 posted)

Building a new Tor that can resist next-generation state surveillance (ars technica)

Comments (none posted)

A bite of Python (Red Hat Security Blog)

Comments (69 posted)

389-ds-base: information disclosure

Comments (none posted)

canl-c: proxy manipulation

Comments (none posted)

charybdis: incorrect SASL authentication

Comments (none posted)

chromium: multiple vulnerabilities

Comments (none posted)

ganglia: cross-site scripting

Comments (none posted)

gd: out-of-bounds read

Comments (none posted)

icu: code execution

Comments (none posted)

java: unspecified vulnerability

Comments (none posted)

jsch: path traversal

Comments (none posted)

kernel: three vulnerabilities

Comments (none posted)

kibana: two vulnerabilties

Comments (none posted)

libksba: denial of service

Comments (none posted)

libstorage: password disclosure

Comments (none posted)

libtomcrypt: signature forgery

Comments (none posted)

mailman: password disclosure

Comments (none posted)

mozilla-thunderbird: unspecified vulnerabilities

Comments (none posted)

tiff3: two vulnerabilities

Comments (none posted)

tomcat: redirect HTTP traffic

Comments (none posted)

Kernel release status

Stable updates: 4.7.3, 4.4.20, and 3.14.78 were released on September 7. Note that the 3.14 long-term series is finally coming to an end, with only one more update planned.

Comments (1 posted)

Quotes of the week

Comments (4 posted)

Audit, namespaces, and containers

Richard Guy Briggs works on the kernel's audit subsystem for Red Hat and has run into some problems with the interaction between the audit daemon (auditd) and namespaces. He gave a report on those difficulties to the Linux Security Summit in Toronto. In the talk, he also looked at containers and what they might mean in the context of audit.

Audit was started in 2004, around the same time that the kernel started using Git. It is a "syslog on steroids", he said. Syslog is used a lot for debugging, but audit is meant as a secure audit trail to log kernel and other events in a way that could be used in court. There are configurable filters in the kernel for what events should be logged and it has the auditd user-space daemon that can log to disk or the network.

Audit only reports on behavior; it does not actively interfere with what is going on in the system. There is one exception, though: audit can panic the system if it cannot log its data.

Briggs then went through a bit of an introduction to namespaces in Linux, noting that they are a kernel-enforced user-space view of the resource being namespaced. There are seven different namespaces in Linux; three are hierarchical in nature (PID, user, and control groups), which means their permissions and configuration are inherited from the parent namespace, while the other four are made up of peer namespaces (mount, UTS, IPC, and net).

He is not sure that anyone actually uses IPC namespaces, he said, but the net namespace is one of the easier ones to understand. Network devices can be assigned to a net namespace from the initial net namespace, so each namespace can have its own firewall rules, routing, and so on. If two namespaces need to talk, a virtual ethernet pair can be set up between them.

The user namespace has been "the most contentious one so far", as there are a number of "security traps" in allowing unprivileged users to be root within the namespace. Many distributions don't enable the feature by default at this point. The control groups (cgroups) namespace, which is the most recent namespace (added in 4.6), is meant to hide system-resource limits so that processes only see what resources have been allocated to their cgroup.

Namespaces are one component of the concept of containers, but there really is no hard definition of containers, Briggs said. In fact, there are almost as many definitions as there are users of containers. There is some general agreement that containers use a combination of namespaces, cgroups, and seccomp to partition some portion of the system into its own world.

But the kernel has no concept of a container at all. Managing containers is left up to a user-space container-orchestration system of some kind. From an audit perspective, though, there is interest in having some knowledge of containers in the kernel. That might be through some form of "container ID" or simply by collecting up the namespace IDs that correspond to the container.

Problems

With that introductory material out of the way, he turned to the problems, which boil down to a Highlander quote: "There can be only one." The "one" in this case is auditd, which runs in the initial namespace but must be reachable from the other namespaces. For the mount, UTS, and IPC namespaces, there have been no problems, but others do have a variety of issues.

For example, the net namespace partitions netlink sockets (which processes use to talk to the audit subsystem) so that only processes in the initial network namespace can send their audit messages. That broke various container implementations because things like pluggable authentication modules (PAM) would try to write an audit message and get an unexpected error return. Instead of the ECONNREFUSED error that it expected when auditd cannot be reached, PAM-using programs (e.g. the login process) would get EPERM and fail such that users could not log in. The short-term solution for that was to simply "lie" in non-initial namespaces and return the expected error message so that user-space programs do not break.

For PID namespaces, the problem cropped up with vsftpd authentication that wanted to write a log message to auditd. Until 3.15, that could only be done from the initial PID namespace, where processes could see the PID of auditd. Some distributions put vsftpd in its own PID namespace, however, which meant that vsftpd could not talk to auditd. By adding the CAP_AUDIT_WRITE capability to the program and adding some code in 3.15, though, that could be worked around.

PID namespaces also present another problem for audit: the PIDs that get reported are not the "real" PIDs in the system. Processes within a PID namespace get their own PID range that is separate from the PIDs in the parent namespace (which might be the initial namespace where the real system PIDs are used). So audit needed to do a translation of the PID reported from non-initial PID namespaces. Someday, when CAP_AUDIT_CONTROL is allowed in PID namespaces (so that processes with that capability can configure the audit filters), there will need to be more cleanup done on the PID handling in the kernel, he said.

Allowing multiple auditd processes in the system would be reasonable if they are tied to user namespaces. There was an idea "thrown around" about creating a new audit namespace, but it became clear that yet another namespace was not a particularly popular idea. Having one auditd per user namespace still requires some process having CAP_AUDIT_CONTROL within the namespace. He wondered if the process creating the user namespace also needed that capability.

Beyond that, the configuration of audit running in the initial namespace cannot be changed from inside user namespaces even with the capability. In particular, only the initial namespace audit can panic the system; instead of that, the audit in a user namespace might instead kill off the user namespace and all its children if it cannot log (thus wants to panic). So each user namespace will get its own set of audit rules (a "rulespace") and its own event queue. Originally it was thought that the event queue might be shared by all of the auditd processes, but a single one that overflowed the queue would affect the rest of the system, which is unacceptable, Briggs said.

There is interest in being able to track containers by some kind of ID. There was a proposal in 2013 to use the /proc inode number that uniquely identifies each namespace in the audit log messages. He felt that was harder to use, so he prototyped a simple incrementing serial number for each namespace. The checkpoint/restore in user space (CRIU) developers were not happy with that, since those numbers would not easily translate during a migration.

Eventually, Briggs reworked the inode-number-based scheme to work with the namespace filesystem (nsfs). Each event then has a set of namespace IDs along with a device ID for the nsfs. That allows container orchestration systems to track the information, even across migrations, which allows them to aggregate logs from multiple hosts.

An alternative would be to add a "container ID" that would be set by the orchestration system and tracked in the task structure. The container ID would be inherited by children and audit events would contain the ID. There is precedent for this kind of ID, he said; session IDs are not something the kernel itself knows anything about, but it helps user space manage those values.

In conclusion, he said that namespace support for audit is largely working at this point, though changes for net and PID namespaces will be needed down the road. There is work to be done to allow multiple auditd processes anchored to the user namespace, as well. As far as IDs go, there is a decision to be made between the list of namespace IDs versus a single kernel-managed container ID. He favors the former, even though dealing with eight separate numbers is harder to use. Either solution will require higher-level tools to map, track, and aggregate information about the containers across multiple hosts.

[I would like to thank the Linux Foundation for travel support to attend the Linux Security Summit in Toronto.]

Comments (4 posted)

Atomic patterns 2: coupled atomics

Our recent survey of the use of atomic operations in the Linux kernel covered the use of simple flags and counters, along with various approaches to gaining exclusive access to some resource or other. On reaching the topic of shared access we took a break, in part because reference counts, which are the tool for managing shared access, have been covered before. Much of that earlier content requires no more than a brief recap, but the use of biases, then described as an anti-pattern, is worthy of further examination as it is a stepping stone toward understanding a range of other patterns for the use of atomics in the kernel.

Recap: three styles of reference counters

I previously identified three styles of reference counters used in Linux; my recent explorations have found no reason to adjust that list. The distinction between the three involves what happens when the count reaches zero.

When a "plain" reference count reaches zero, nothing particular happens beyond the obvious. Some code somewhere might occasionally check if the counter is zero and behave differently if it is, but the moment of transition from non-zero to zero has no significance. A good example is child_count used by the runtime power management code. This allows a "child" device to hold a reference on its parent to keep it active. Unless it has been configured to ignore_children, the parent will be kept active as long as any child still holds a reference.

When a "kref" reference count reaches zero, some finalization operation happens on the object; typically it is freed. Code requiring that pattern should use the struct kref data type, though an atomic_t counter and atomic_dec_and_test() can be used if there is a good reason to avoid kref.

Finally, the "kcref" counter is not allowed to reach zero unless a lock is held. Code implementing this pattern can use atomic_dec_and_lock(), which takes a spinlock only if it is likely to be needed. A more general approach that can work with any sort of lock is to have a fast path that uses atomic_add_unless() to decrement the counter as long as its value is not one. If this fails, the lock can be taken and at atomic_dec_and_test() or similar can be used. hw_perf_event_destroy() in the perf code displays this quite nicely.

Counter bias: multiple values in the one atomic

A number of reference counters in Linux (e.g. in procfs and kernfs) have a "bias" added to the value. This bias is a large value (larger than the normal range of the counter) that can be added to the counter's value. The presence or absence of the bias can easily be detected even as the counter itself moves up or down. This allows a boolean value to be stored in the same variable as the counter. I previously described this as an anti-pattern; a proper solution would instead use a separate variable (or bit in a bitmap) to store the boolean value. When the counter and the boolean are changed independently, I stand by that assessment, but sometimes there is value in being able to control them together in a single operation.

A particularly simple example is found in the function-tracing (ftrace) code for the SuperH architecture. The nmi_running counter sometimes has its most significant bit set, effectively using a bias of 2³¹. This flag, which is used to provide synchronization between ftrace and non-maskable interrupt handlers, may be cleared at any time, but may only be set when the value of the counter is zero. Normally, when there is a need to synchronize the change in one value with some other value, it is simplest to hold a spinlock whenever either value is changed — but that is not necessarily the fastest way. If the two values of interest can be stored in the same machine word, then an atomic compare-exchange operation, often in a loop to handle races, can achieve the same end more efficiently.

Having identified this pattern of two values being managed with a single atomic operation, we need a name for it; "coupled atomics" seems a good choice as the interdependence between the two values could be seen as a coupling. Other examples of this pattern are easy to find. The "lockref" type that was introduced in Linux 3.12 follows exactly this pattern, storing a 32-bit spinlock and a 32-bit reference count in a single 64-bit word that, on several popular architectures, can be updated atomically. Even this 32-bit spinlock itself is sometimes a multi-part atomic, as is the case for both ticket spinlocks and MSC locks.

The previous article mentioned two uses for the new atomic_fetch*() operations; we can now add a third. This one involves an atomic_t variable that contains a counter and a couple of flags, only this time the flags are in the least significant bits and the counter is in the higher-order bits. This atomic_t is used to implement a queued reader/writer spinlock. The flags record if a write lock is held, or if a writer is waiting for the lock. The counter, which is incremented by adding 256 (using the defined name _QR_BIAS) records the number of active readers. A new reader attempts to get a read lock using an atomic operation to add _QR_BIAS and then see if either of the flags were set in the result. If they were set, the read lock was not acquired; the failed reader subtracts the bias and tries again. Interestingly, the fast path code uses atomic_add_return(), while the slow path code uses the new atomic_fetch_add_acquire(). Either is quite suitable for the task, but a little more consistency would be nice.

Another example is the helpfully named combined_event_count counter in the system suspend code. This variable stores two counters: the number of in-progress wakeup events and the total number of completed wakeup events. When the in-progress counter is decremented, the total needs to be incremented; by combining the two counters in the one atomic value, the two can be updated in a single race-free operation.

More coupled atomics, big and small

Examples so far could be seen as mid-range examples, combining a counter with some other modestly sized value, typically another counter or a flag, into the one atomic value. To finish off we will look at two extremes in size, the largest and smallest.

Most atomics are 32 bits in size, though 64-bit values, whether pointers manipulated with cmpxchg() or the atomic_long_t type, are not exactly uncommon. What is uncommon is 128-bit atomic types. These are limited to three architectures (arm64, x86_64, and s390) and to a small number of users, mainly the SLUB memory allocator.

SLUB owns several fields in the page description structure: a pointer to a list of free space, some counters of allocated objects, and a "frozen" flag. Sometimes it wants to access or update several of these atomically. On a 32-bit host, these values all fit inside a 64-bit value. On a 64-bit machine, they don't, so a larger operation is needed; cmpxchg_double() is available on the listed architectures to allow this. It is given two pointers to 64-bit memory locations that must be consecutive, two values for comparison, and two values for replacement. Unlike the single-word cmpxchg() that always returns the value that was fetched, cmpxchg_double() returns a success status, rather than trying to squeeze 128 bits into the return value.

On 64-bit architectures without this 128-bit atomic option, SLUB will use a spinlock to gain the required exclusive access — effective, but not quite as fast. cmpxchg_double() seems to me to be an eloquent example of the lengths some kernel developers will go to in order to squeeze out that last drop of performance.

The other extreme in size is to combine two of the smallest possible data types into a single atomic: two bits. A simple example in the xen events_fifo code clears one bit, EVTCHN_FIFO_MASKED, but only when the other bit, EVTCHN_FIFO_BUSY is also clear. Manipulating multiple bits at once is another place where the new atomic_fetch*() operations could be useful. They do not support any dependency between bits as we see in the xen example, but they could, for example, clear a collection of bits atomically and report which bits were cleared, by using atomic_fetch_and(). Similarly, if an atomic_t contained a counter in some of the bits, that counter could be extracted and zeroed without affecting other accesses. Whether these are actually useful I cannot say as there are no concrete examples to refer to. But the pattern of multiple values in the one atomic_t does seem to raise more possible uses for these new operations.

Both a strength and a weakness

Having found these various patterns, several of which I did not expect, the overall impression I am left with is the tension between the strength and the weakness of C for implementing these patterns. On the one hand C, together with the GCC extensions for inline assembly language code, provides easy access to low-level details that make it possible to implement the various atomic accesses in the most efficient way possible. On the other hand, the lack of a rich type system means that we tend to use the one type, atomic_t, for a wide range of different use cases. Some improvements might be possible there, as we saw with the introduction of the kref type, but I'm not sure how far we could take that. I contemplate the atomic_cmpxchg_double() usage in SLUB and wonder what sort of high-level language construct would make that more transparent and easy to read, and yet keep it as performant on all hardware as it currently is. It certainly would be nice if some of these patterns were more explicit in the code, rather than requiring careful analysis to find.

Comments (none posted)

Reimplementing mutexes with a coupled lock

A mutex is a sleeping lock, meaning that kernel code that tries to acquire a contended mutex may go to sleep to wait until that mutex becomes available. Early mutex implementations would always put a waiter to sleep, but, following the scalability trends of the day, mutexes soon gained a glamorous accessory: optimistic spinning. Waking a sleeping thread can take a long time and, once that thread gets going, it may find that the processor cache contains none of its data, leading to unfashionable cache misses. A thread that spins waiting for a mutex, instead, will be able to grab it quickly once it becomes available and will likely still be cache-hot. Enabling optimistic spinning can improve performance considerably. There is a cost, in that mutexes are no longer fair (they can be "stolen" from a thread that has been waiting for longer), but being properly à la mode is never free.

Optimistic spinning brings with it an interesting complication, though, in that it requires tracking the current owner of the mutex. If that owner sleeps, or if the owner changes while a thread is spinning, it doesn't make any sense to continue spinning, since the wait is likely to be long. As a field within the mutex, the owner information is best protected by the mutex itself. But, by its nature, this information must be accessed by threads that do not own the mutex. The result is some tricky code that is trying to juggle the lock itself and the owner information at the same time.

Peter Zijlstra has sent an alternative mechanism down the runway; it takes care of this problem by combining the owner information and lock status into a single field within the mutex. In current kernels, the count field, an atomic_t value, holds the status of the lock itself, while owner, a pointer to struct task_struct, indicates which thread owns the mutex. Peter's patch removes both of those fields, replacing them with a single atomic_long_t value called "owner".

This value is 64 bits wide, large enough to hold a pointer value. If the mutex is available, there is no owner, so the new owner field contains zero. When the mutex is taken, the acquiring thread's task_struct pointer is placed there, simultaneously indicating that the mutex is unavailable and which thread owns it. The task_struct structure must be properly aligned, though, meaning that the bottom bits of a pointer to it will always be zero, so those bits are available for other locking-related purposes. Following this season's coupled-lock trend, two of those bits are so used, in ways that will be described shortly.

With the new organization, the code to attempt to acquire a mutex now looks like this:

    static inline bool __mutex_trylock(struct mutex *lock)
    {
    	unsigned long owner, curr = (unsigned long)current;
    
    	owner = atomic_long_read(&lock->owner);
    	for (;;) { /* must loop, can race against a flag */
    	    unsigned long old;
    
    	    if (__owner_task(owner))
    		return false;
    	    old = atomic_long_cmpxchg_acquire(&lock->owner, owner,
    					      curr | __owner_flags(owner));
    	    if (old == owner)
    		return true;
    	    owner = old;
    	}
    }

The __owner_task() and __owner_flags() macros simply mask out the appropriate parts of the owner field. The key is the atomic_long_cmpxchg_acquire() call, which attempts to store the current thread as the owner of the mutex on the assumption that it is available. Should some other thread own the mutex, that call will fail, and the mutex code will know that it will have to work harder.

There are currently two flags that can be stored in the least significant bits of owner. If a thread finds it must sleep while waiting for a contended mutex, it will set MUTEX_FLAG_WAITERS; the thread currently holding the mutex will then know it must wake the waiters when the mutex is freed. Most of the time, it is hoped, there will be no waiters; maintaining this bit allows for a bit of unnecessary work to be skipped.

As mentioned above, optimistic spinning, while good for performance, is unfair; in the worst case, an unlucky thread contending for a highly contended mutex could be starved for a long time. In an attempt to prevent that problem, the second owner bit, MUTEX_FLAG_HANDOFF, can be used to change how a contended mutex changes ownership.

If a thread tries and fails to obtain a mutex after having already slept waiting for it to become available, it can set MUTEX_FLAG_HANDOFF prior to returning to sleep. Later on, when the mutex is freed, the freeing thread will notice the flag and behave differently. In particular, it must avoid clearing the owner field as it normally would, lest some other thread, spinning on the mutex, steal it away. Instead, it finds the first thread in the wait queue for the mutex and transfers ownership directly, waking that thread once the job is done. This dance restores some fairness, at the cost of making everybody wait for the sleeping thread to wake up and get its work done.

The new code simplifies the mutex implementation considerably by getting rid of a number of strange cases involving the separate count and owner fields. But it gets a bit better than that, since the new code is also architecture-independent; all of the old, architecture-specific mutex code can go away. So the bottom line of Peter's cover letter reads:

    49 files changed, 382 insertions(+), 1407 deletions(-)

Removing code, as it happens, is always in fashion, and removing 1000 lines of tricky assembly-language locking code is especially chic. Assuming that this code manages to avoid introducing performance regressions, it could be a must-have item at a near-future merge-window ball.

Comments (1 posted)

Building a GNOME-based automotive system

At GUADEC 2016 in Karlsruhe, Germany, Lukas Nack presented a look at Apertis, the open-source automotive in-vehicle infotainment (IVI) system developed by Bosch. Apertis makes use of a number of GNOME components for its application framework, in contrast to many IVI products built by car makers. But, as the audience questions at the end of the session revealed, there may still be some significant disconnects between the free-software community and automotive industry decision makers.

The car market

Nack began by outlining the increasingly computerized aspects of modern cars and how open source (namely Linux systems) is expected to play a significant role in the coming years. In the future, cars will come with computerized IVI head units in the dashboard, computerized instrument clusters, separate passenger entertainment systems, and likely several other software-driven panels (such as the climate-control system). Already, most new cars come with a seven-to-nine-inch screen in the IVI unit, which provides audio control, phone connectivity access, navigation, and other services.

These IVI head units are not chosen by the user, though; they are provided by the car maker as built-in equipment that the manufacturer puts through a multi-year test phase in order to meet safety and reliability requirements. The car industry, Nack said, is not quick to adopt new technology. The safety regulations are one reason why, but there are others, including the long maintenance period (product lifespans averaging ten years or more) and the difficultly of building systems that are robust in the automotive environment. For example, automotive computers must not crash even when the available voltage supply suddenly drops or the ignition is shut off without warning.

The result is that developing IVI software is more complicated than developing a typical desktop system, he said. Car makers want app-store like environments similar to what users have on their smartphones, but they also want a platform that they can customize to serve in a wide range of different vehicles. They are also quite concerned with safety issues, he said. They want to avoid the security vulnerabilities routinely demonstrated by researchers, and they are averse to using GPLv3 software primarily because they want to "Tivoize" their systems. That desire, he said, comes from their fear that people will modify the software in their car and people will die in an accident as a result.

Bosch is primarily a supplier to the auto industry (although it has several other industrial engineering interests), making components from braking systems to navigation and car stereo units for use by car makers. Apertis is Bosch's automotive Linux distribution, which it has developed to be used and adapted by car makers as well. Nack outlined its major features.

Apertis

The distribution is an Ubuntu derivative that ships a GENIVI-compliant middleware stack. On top of that, Bosch has built an application framework using GTK+ and GNOME. There are two reference hardware designs supported in the official release images: the MinnowBoard MAX for Intel systems and the i.MX6 SABRE Lite for ARM. The project also produces development tools that can be installed and run on the target system itself. The original code is released under the MPLv2.

For its application framework, Nack said, Apertis chose GNOME over Qt—largely because it found Qt to "be very closed." "It's hard to break out of," he said, whereas GNOME is totally different. "You can use whatever you want; there are lots of language bindings, and you can exchange any components you want to."

The Apertis framework distinguishes between built-in applications and "apps" that would come from a smartphone-like app store. These apps are installed from self-contained bundles (which include their dependencies) and are run in a sandboxed environment. The Apertis sandboxing system appears to have been developed entirely within Bosch, but it follows the same basic outlines as other application-sandboxing systems. AppArmor is used to enforce access control, control groups restrict access to system resources, and polkit is used as a second-level mechanism to limit access to the system.

Each app can read and write files in a private directory, and access to a shared storage directory must be authorized interactively by the user. An app-launcher process is responsible for installing apps, checking the permissions each app requests in its manifest file and whitelisting it with the necessary AppArmor policy. The launcher also handles app upgrades, starting and stopping apps, and uninstallation.

Apertis offers a set of APIs that track the automotive APIs defined by GENIVI and the World Wide Web Consortium. In addition, Apertis supports "agent" processes, which are essentially standard daemons. In addition to native GTK+ apps, HTML5 apps are supported (running on WebKit2GTK).

The developer community

At present, Apertis is not shipping in any cars and Nack did not disclose any such plans. The system is similar in most respects to the GENIVI-based products being developed elsewhere (including by car makers), though building the system on Ubuntu rather than with Yocto is a distinction, as is the choice of GNOME over Qt.

The GNOME developers and community members in the audience had quite a few questions, beginning with whether or not Bosch had seen any of the application-sandboxing work done in Flatpak. Nack replied that he was not familiar with it himself, but that the project had been asked about it. Flatpak developer Alex Larsson (who was moderating the question-and-answer session) noted that the Apertis sandbox design seemed "almost exactly the same" and suggested that Bosch explore Flatpak.

Several other audience members pushed back on various comments from the presentation about locking the system down. Bradley Kuhn asked whether or not an Apertis system would come with the necessary scripts for users to modify and install their own version; Nack replied that he did not know. Kuhn also objected to the notion that avoiding GPLv3 software would prevent fatalities. He pointed out that the Tesla self-driving car component was proprietary and it has killed someone and that Volkswagen's proprietary emissions-cheating software was, in a sense, killing lots of people slowly by contributing excess pollution.

Christian Hergert, who described himself as "a recovering car guy" noted that it currently takes a lot of reverse engineering to decode the proprietary diagnostic codes emitted by Bosch head units, and asked whether Apertis, with access to a nice seven-inch monitor, could save everyone a lot of trouble by displaying human-readable error messages instead. He also asked whether the opaque settings Bosch head units currently stored in 32-bit flag fields would become something more convenient like GSettings keys. Nack replied that he was not sure, but that he suspected Apertis would typically be deployed as a guest OS running on top of a separate real-time OS, and that the low-level messages and codes would probably be handled by the real-time component. As to displaying human-readable messages, he replied that he thought Bosch probably does not want anyone to reverse engineer its systems, so it was unlikely to make the job easy for them.

That point prompted a number of audience members to comment on the drawbacks and problems of locking out developers and car owners. Bastien Nocera pointed out that some components, notably WebKit, are guaranteed to have security bugs discovered over a car's ten-year lifespan. If developers cannot fix those packages, drivers are being placed at greater risk. Other points include the possibility that a car maker will go out of business, leaving users locked out and with no chance of even a vendor-provided update, and the fact that locking down the system imposes a long-term maintenance burden on the manufacturer.

To a degree, Nack seemed taken by surprise at how many questions the audience had on the topic of lock-down. He generally tried to abstain from making pronouncements on what Bosch's position (or any Apertis-using car maker's opinion) would be, noting that the automotive industry, in general, is not particularly open toward aftermarket development. "I think car manufacturers need to change their thinking about this," he said, "but I don't see that happening in the near future."

Given their alignment on technologies, in theory Apertis could become a project that works closely with GNOME, to the benefit of both camps. But there are clearly obstacles to that taking place, if the higher levels at Bosch or car makers are, indeed, averse to engaging with free-software developers like they would the supplier of any other component. That said, one should surely not extrapolate too much from a single Q&A session; as GENIVI and other automotive Linux projects have found, it is possible to shift the thinking of automotive industry players.

But it will likely take a lot more engagement between the two communities before the interests of automotive manufacturers are fully in line with the interests and needs of the free-software development community. Hopefully engaging with GNOME will increase the chances of that alignment happening soon.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]

Comments (2 posted)

Distribution quotes of the week

Comments (8 posted)

OpenBSD 6.0

Comments (6 posted)

Reminder - Debian Bug Squashing Party in Salzburg, Austria

Full Story (comments: none)

Fedorahosted.org sunset

Full Story (comments: 11)

Distribution newsletters

• DistroWatch Weekly, Issue 677 (September 5)
• Lunar Linux weekly news (September 2)
• openSUSE news (September 2)
• openSUSE news (September 7)
• openSUSE Tumbleweed – Review of the Week (September 4)
• Ubuntu Kernel Team newsletter (August 30)
• Ubuntu Weekly Newsletter, Issue 480 (September 4)

Comments (none posted)

An asynchronous Internet in GNOME

At GUADEC 2016 in Karlsruhe, Germany, Jonathan Blandford challenged the GNOME project to rethink how its desktop software uses network access. The GNOME desktop assumes Internet connectivity is always available, which has the side effect of making the software stack considerably less useful and, indeed, usable to people who live in those places regarded as the developing world.

Blandford currently works for Endless Mobile, which makes computers for the developing world, he said, using GNOME as its desktop environment. He is also one of GNOME's longest-serving project members, having been a GNOME developer at Red Hat long before the 1.0 release.

The Internet is ubiquitous in people's lives and is fundamental to most software, Blandford said, so most developers lapse into thinking about it as omnipresent. But, in fact, Internet access is neither "always on" nor is it cheap in many places around the globe. "Less than half of humanity has access to it today," he said. Thus, software that takes Internet connectivity for granted fails to function for users in the developing world. "We're seeing a split between 'Internet-haves' and 'Internet have-nots.'"

But, he added, the fact that the software industry as a whole lets this market down means that there is an opportunity for GNOME to do better than simply follow the status quo. "And I'm as guilty of this as anyone," he admitted. Nine years ago, he noted, when he worked on GNOME as part of Red Hat's desktop team, that team fully embraced the concept of the "online desktop" that would seamlessly integrate with remote services—which has worked out well for the software project, but has left a lot of people behind.

The barriers that keep ubiquitous high-speed Internet connectivity out of the hands of most of the world's population are fairly well known. Infrastructure costs associated with wired networks mean that the majority of the world uses cellular connections for network access. In addition, data charges are frequently too high for many people, and the bulk of the Internet remains rather English-centric. Finally, while bandwidth is increasing rapidly in the US and Europe, speeds are creeping up far less rapidly everywhere else around the globe.

With the majority of GNOME developers hailing from Europe and North America, Blandford said, the project needs to adopt a new mindset in order to serve users in the developing world. He then showed some raw numbers regarding speeds and pricing in different areas of the world. One of the most striking was that the average desktop uses 60GB of data every month in the developed world—a number far too high to be sustainable elsewhere.

Blandford then pointed out that although a lot of time is spent discussing "instant data" like email and social media messages—data that users consider highly valuable—such data makes up only a tiny fraction of the overall Internet bandwidth. The majority is "cacheable data," he said, like web pages and video content that is produced once and requested many times.

Currently, cacheable data is "extremely expensive," he said; although media companies use commercial content-delivery networks (CDNs) for the developed world, the same data is virtually inaccessible in the developing world. So one important way GNOME could improve the computing experience for people in the developing world is to build an "asynchronous Internet" within the GNOME desktop, utilizing alternative means to distribute and store cacheable data.

People have already created various methods to distribute data in bulk outside the Internet, he noted. El Paquete Semanal, for example, is a hard drive image circulated weekly in Cuba through underground means, currently including about 2TB of data. The Android app Zapya lets users download a web site to their phone while they are online at some public location, saving it to read (and share) once at home. In both cases, the latency of these "networks" is exceptionally high, but the overall throughput of a hard drive delivered weekly via motorbike is pretty good, he noted.

There are also projects like Toosheh, which uses television satellites to "backpack" one-way data signals onto unused bandwidth, enabling users in Iran who have satellite dishes to access web content that is officially censored by the government. Endless has discussed the idea of cell network providers letting users download data at reduced rates overnight when there is substantially less demand for voice service. And, of course, peer-to-peer technologies like BitTorrent are widely used in the developing world to distribute data.

But raw support for asynchronous network access is only one piece of the puzzle: applications would need to support data access through different means, such as offline caches. This is an area where Endless has already been working, Blandford said. Endless systems include a variety of GTK+-based applications that use local data caches to provide access to informational content (from news to topical, Wikipedia-like references). They retrieve updates from Endless servers in off-peak hours, if there is Internet access.

GNOME could adapt similar techniques for many of its applications, he said. The existing GNOME Recipes application, for example, retrieves recipes live over the web; the equivalent Endless app uses a local database that is updated incrementally when it is convenient. Still, he said, his goal was not to dictate that GNOME copy Endless's designs, but rather to inspire the GNOME community to think about how it could improve offline usability in its applications.

There are several areas where GNOME applications can improve, he said. The first is to stop assuming connectivity is available and to build in ways to deal gracefully with connectivity problems and disconnects. "And I'm looking at you, Evolution," he said. Dealing with degraded connectivity includes being careful not to download data more than once, he added. The second is to be conscious of the user's bandwidth, including being explicit about when the application is using the network. "It's a precious resource," he said, "It's not 'free.'" Android works along those lines already with the "download for offline use" options in Google Maps and Translate, he said, but so far GNOME does not use that design pattern. Related to that improvement area is "aggressively caching data," he said, as in the Endless examples.

Other areas for improvement include expanding language support and developing documentation that reaches beyond GNOME's existing stable of users and developers. This is an area in which the project already does a good job, he said, but it needs to go further. Although GNOME takes a lot of flak for simplifying the desktop too much, Blandford said, Endless found in its real-world user tests that much of the documentation and the wording used on the desktop was written to serve a small niche of college-educated people with extensive experience with technology concepts. Ultimately, the point is that developing a desktop system for the entire world requires recognizing that "our needs" are not "everyone's needs."

Blandford ended by proposing that asynchronous Internet support be added to the list of concepts that GNOME cares about, like accessibility and internationalization—he suggested "a18t" as one possible abbreviation, and "Int··n·t" (for "spotty Internet) as another.

Whatever the abbreviation is, he concluded, this is a concept that GNOME should think about while it develops its software. Most of the people who are not yet online want to get online, Blandford said, and when it comes to the desktop software they use, they have not picked one yet. So GNOME's opportunity with asynchronous networking support is a chance to serve an underserved population, but also to grow the GNOME community with new people who are excited about getting access to computing.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]

Comments (29 posted)

Quotes of the week

Comments (2 posted)

Z-Wave protocol specification now public

The Z-Wave wireless home-automation protocol has been released to the public. In years past, the specification was only available to purchasers of the Z-Wave Alliance's development kit, forcing open-source implementations to reverse-engineer the protocol. The official press release notes that there are several such projects, including OpenZWave; Z-Wave support is also vital to higher-level Internet-of-Things abstraction systems like AllJoyn.

Comments (21 posted)

Anticipating KDE's 20th anniversary

Comments (1 posted)

LLVM 3.9 released

Full Story (comments: 2)

Git v2.10.0

Full Story (comments: none)

Samba 4.5.0 is available

Samba version 4.5.0 has been released. Among the included changes, the NTLMv1 authentication option has been disabled by default, multiple DNS forwarders are now supported on the Active Directory Domain Component, and SMB 2.1 leases are now enabled by default. See the announcement for the full list of new features.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (August 31)
• What's cooking in git.git (September 2)
• This Week in GTK+ (September 5)
• OCaml Weekly News (September 6)
• Perl Weekly (September 5)
• PostgreSQL Weekly News (September 4)
• Python Weekly (September 1)
• Python Weekly (September 8)
• The R Journal (August)
• Ruby Weekly (September 1)
• Ruby Weekly (September 8)
• This Week in Rust (September 6)
• Wikimedia Tech News (September 5)

Comments (none posted)

Tor: A New Bridge Authority

The Tor blog has announced that the network's current bridge authority, an infrastructure server that keeps track of Tor's unpublished entry nodes ("bridges"), is being decommissioned and will be replaced with a new server donated by a new provider. The new authority, Bifröst, will be gradually taking over duties from the old authority, Tonga. "This transition does not affect Tor users, regardless of whether or not Bridges are used to connect to the Tor network. However, it is extremely important that relay operators running Bridges upgrade to tor-0.2.8.7 or tor-0.2.9.2.-alpha, which contains a patch to replace Tonga with the new Bridge Authority." Bridges that do not upgrade will no longer be used for incoming connections. The post also notes that several opportunities exist for interested developers to improve how Tor bridges are tracked and managed.

Comments (none posted)

Suspect in kernel.org breakin arrested

Comments (31 posted)

Linux Foundation conference videos

Comments (1 posted)

Videos from QtCon/Akademy

Comments (none posted)

Free Software Supporter Issue 101, September 2016

Full Story (comments: none)

FSFE: Julia Reda, MEP: "Proprietary Software threatens Democracy"

Full Story (comments: none)

Danko: Next steps for Gmane

Comments (23 posted)

3rd Call For Papers - 23rd Annual Tcl/Tk Conference (Tcl'2016)

Full Story (comments: none)

CFP Deadlines: September 9, 2016 to November 8, 2016

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

Audio workshop accepted for Linux Plumbers Conference and Kernel Summit

LPC registration is open with a limited number of slots available. There will also be a small number of late registrations available starting on October 1.

Full Story (comments: none)

Nextcloud Conference: Keynote Speakers

Comments (none posted)

Events: September 9, 2016 to November 8, 2016

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