The year-2038 problem will ultimately affect all code that uses 32 bits for time values. Over the past year, the Linux kernel community has begun formally hashing out its plan to transition to 64-bit time support. As a result, other development teams have been observing the kernel discussion and have started to plan their own approaches. The GNU C library (glibc) is one such project, and its developers recently drafted an initial plan of attack.

Albert Aribaud unveiled a proposed plan on the glibc mailing list on October 26, soliciting feedback. Aribaud's proposal sets out a few straightforward requirements for any eventual game plan. As was discussed in 2014, glibc will add a feature test macro that 32-bit applications can set to enable the use of year-2038-safe, 64-bit time functions—although the details surrounding the macro have changed since it was first proposed.

TIME BITS and macros

The interfaces that glibc presents to user code have been the subject of most of the debate thus far. The project had previously considered supporting both 64-bit and 32-bit time functions in the same application.

The first draft of the proposed plan provided both a _TIME64_SOURCE macro and a _TIME_BITS macro. Defining _TIME64_SOURCE would make 64-bit time functions available to the application; then defining _TIME_BITS=64 would cause all time functions to use 64-bit times by default. The _TIME_BITS=64 option is implemented by transparently mapping the standard functions and types to their internal 64-bit variants. Glibc would also set __USE_TIME_BITS64 , which user code can test for to determine if the 64-bit variants are available.

A subtle effect caused by using two macros in this manner, though, is that it could enable user code to activate 64-bit time functions, but still default to using the 32-bit versions. In essence, that would allow an application to mix and match calls to (hypothetically) clock_gettime() and clock_gettime64() .

On that point, some similarities were cited to the project's addition of the Large File Support (LFS) extension several years ago. The LFS extension provided a _FILE_OFFSET_BITS feature test macro; setting _FILE_OFFSET_BITS=64 would cause glibc to remap off_t and the related functions (e.g., ftello() and fseeko() ) to their 64-bit equivalents ( off64_t , ftello()64 , and fseeko64() ). But glibc also provided another option, _LARGEFILE64_SOURCE , that made the 64-bit types and functions available in addition to the 32-bit flavors.

Opinion is sharply divided as to whether or not this was a good idea; code calling the *64 functions is neither portable to other C libraries nor does it conform to standards. The same problem could plague the 64-bit time implementation, with _TIME64_SOURCE and _TIME_BITS=64 being analogous to _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 .

Rich Felker recommended not repeating the LFS approach when implementing 64-bit time:

Personally I would rather NOT have this functionality, because my experience from the off_t fiasco was that lots of applications erroneously started using the 64-suffixed functions/types rather than defining _FILE_OFFSET_BITS=64, resulting in messy, non-portable, non-standards-conforming code that took a long time to fix. But I suspect lots of people want it.

Not everyone concurred that the LFS approach was a bad one; Myers noted that the LFS transition, which was trickiest for third-party libraries using glibc, was eventually managed. In a separate email, though, he also expressed doubt that there were many use cases where code would need explicit access to the *64 versions of any functions. Without such use cases, having _TIME_BITS=64 both "enable" and "select" 64-bit time would be simpler.

Aribaud did remove _TIME64_SOURCE from the subsequent drafts of the plan. As things stand now, only the _TIME_BITS macro remains.

Further issues

Some points still up for discussion include whether to mandate that 64-bit time only be supported where 64-bit file offsets are supported (essentially, LFS systems), and whether there should be an attempt to fix 32-bit time functions or simply to implement 64-bit time functions and provide them for those developers wanting a solution.

Not supporting 64-bit time on systems without 64-bit file offsets would primarily serve to reduce the complexity of the implementation—that is, there would only be two permutations to consider (32-bit and 64-bit), rather than four (all 32-bit, all 64-bit, 32-bit time with 64-bit file support, and 64-bit time with 32-bit file support). There are, presumably, only a few non-LFS systems left in the wild, so not supporting them likely has little impact. In light of the project's somewhat contentious history with supporting 32-bit and 64-bit file offsets simultaneously, imposing this restriction is understandable.

The case for not attempting to fix (whatever that might mean) 32-bit time functions is, simply, that developers should know better and fix their code, using _TIME_BITS=64 to enable the new, 64-bit time functions. Any application that persists in using 32-bit time will see incorrect results for times after January 2038, but perhaps that is acceptable. Presumably, such instances would be rare, such as applications for which no source code is available.

As far as interfacing with the kernel is concerned, the basic idea is that glibc will always convert time-related type sizes between kernel space and user space. If the system is running a year-2038-safe kernel, glibc will also convert time values between kernel space and user space. It will not, however, attempt to convert values for a non-year-2038-safe kernel. A bit more nebulous is how to fix platforms that already use 64 bits to store times, but use them to store 32-bit values. Ideally, the general 64-bit time fix should not break these systems. Myers pointed out that the 32-bit time values on these system will need to have an explicit padding field.

Glibc will still need to implement and verify all of the functions and types affected by 64-bit time. Aribaud is still in the process of mapping out the complete set of APIs affected—directly and indirectly—by changing the size of time_t . But once that set of affected pieces has been determined, the question still remains whether 64-bit time should become the default.

Here again, comparisons were made to the LFS transition process. Ultimately, the large-scale transition that changing the default would trigger is a prospect that no one relishes, since it will inevitably impact many libraries and applications—as well as costing developers and users time. But it will have to happen eventually. Felker suggested that announcing a timeline for changing the default from 32-bit to 64-bit time in advance would help avoid many of the LFS transition's headaches.

For now, no such timeline has been discussed. 32-bit time will remain the default for some time to come; making 64-bit time the default will be left for some as-yet-undetermined future date, and the decision will no doubt involve consultation from distributors. There are plenty of additional details that the glibc developers will need to work out in order to fully support 64-bit time, but reaching a rough consensus on the approach to take and on the interfaces to use is a good first step.

Comments (32 posted)

One of the many weak links in Internet security is the domain name system (DNS); it is subject to attacks that, among other things, can mislead applications regarding the IP address of a system they wish to connect to. That, in turn, can cause connections to go to the wrong place, facilitating man-in-the-middle attacks and more. The DNSSEC protocol extensions are meant to address this threat by setting up a cryptographically secure chain of trust for DNS information. When DNSSEC is set up properly, applications should be able to trust the results of domain lookups. As the discussion over an attempt to better integrate DNSSEC into the GNU C Library shows, though, ensuring that DNS lookups are safe is still not a straightforward problem.

In a sense, the problem was solved years ago; one can configure a local nameserver to perform full DNSSEC verification and use that server via glibc calls in applications. DNSSEC can even be used to increase security in other areas; it can, for example, carry SSH or TLS key fingerprints, allowing applications to verify that they are talking to the right server. Things get tricky, though, when one wants to be sure that DNS results claiming to have DNSSEC verification are actually what they claim to be — when one wants the security that DNSSEC is meant to provide, in other words.

The /etc/resolv.conf problem

Part of the problem, from the glibc perspective, is that glibc itself does not do DNSSEC verification. Instead, it consults /etc/resolv.conf and asks the servers found therein to do the lookup and verification; the results are then returned to the application. If the application is using the low-level res_query() interface, those results may include the "authenticated data" (AD) flag (if the nameserver has set it) indicating that DNSSEC verification has been successfully performed. But glibc knows nothing about the trustworthiness of the nameserver that has provided those results, so it cannot tell the application anything about whether they should really be trusted.

One of the first steps suggested by glibc maintainer Carlos O'Donell is to add an option ( dns-strip-dnssec-ad-bit ) to the resolv.conf file telling glibc to unconditionally remove the AD bit. This option could be set by distributions to indicate that the DNS lookup results cannot be trusted at a DNSSEC level. Once things have been set up so that the results can be trusted, that option can be removed. In the meantime, though, applications would have a way to judge the DNS lookup results they get from glibc, something that does not exist now.

What would a trustworthy setup look like? The standard picture looks something like this: there is a local nameserver, accessed via the loopback interface, as the only entry in /etc/resolv.conf . That nameserver would be configured to do verification and, in the case that verification fails, simply return no results at all. There would, in almost all cases, be no need to worry about whether applications see the AD bit or not; if the results are not trustworthy, applications will simply not see them at all. A number of distributions are moving toward this model, but the situation is still not as simple as some might think.

One problem is that this scheme makes /etc/resolv.conf into a central point of trust for the system. But, in a typical Linux system, there are no end of DHCP clients, networking scripts, and more that will make changes to that file. As Paul Wouters pointed out, locking down this file in the short term is not really an option. Sometimes those changes are necessary: when a diskless system is booting, it may need name-resolution service before it is at a point where it can start up its own nameserver. A system's entire DNS environment may change depending on which network it is attached to. Systems in containers may be best configured to talk to a nameserver on the host. And so on.

So there seems to be a general belief that /etc/resolv.conf cannot really be trusted on current systems. Ideas to add secondary configuration files ( /etc/secure-resolv.conf or whatever) have been floated, but they don't much change the basic nature of the situation. Beyond that, some participants felt that even a local nameserver running on the loopback interface is not really trustworthy; Zack Weinberg suggested that administrators might intentionally short out DNSSEC validation, for example.

Since the configuration cannot be trusted on current systems, the reasoning goes, glibc needs to have a way to indicate to applications when the situation has improved and things can be trusted. That could include the AD-stripping option described above (or, conversely, an explicit "this nameserver is trusted" option); that, of course, would require that the system be locked down to a level where surprising changes to /etc/resolv.conf no longer happen. A variant, as suggested by Petr Spacek, is to have a way for an application to ask glibc whether it is talking to a local nameserver or not.

Do it in glibc?

An alternative would be to dispense with the nameserver and have glibc do DNSSEC validation itself. There is, however, resistance to putting a big pile of cryptographic code into glibc itself. That would increase the size of the library and, it is felt, increase the attack surface of any application using it. A variant of this idea, suggested by Zack, would be to put the validation code into the name-service caching daemon ( nscd ) instead. Since nscd is part of glibc, it is under the control of the glibc developers and there could be a certain amount of confidence that DNSSEC validation is being performed properly. The location of the nscd socket is well known, so the /etc/resolv.conf issues don't come into play. Carlos worried, though, that this approach might deter adoption by users who do not want the caching features of nscd ; in his mind, that seems to rule out the nscd option.

So, in the short term, at least, it seems unlikely that glibc will take on the full task of performing validated DNSSEC lookups. That means that, if security-conscious applications are going to use glibc for their name lookups, the library will have to provide an indication of how trustworthy the results received from a separate nameserver are. And that will almost certainly require explicit action on the part of the distributor and/or system administrator. As Simo Sorce put it:

A situation in which glibc does not use an explicit configuration option to signal applications that it is using a trusted resolver is not useful ... no scratch that, it is actively harmful, because applications developers will quickly realize they cannot trust any information coming from glibc and will simply not use it for DNSSEC related information.

Configuring a system to properly use DNSSEC involves change to many of the components of that system — it is a distribution-wide problem that will take time to solve fully. The role that glibc plays in this transition is likely to be relatively small, but it is an important one: glibc is probably the only place where applications can receive some assurance that their DNS results are trustworthy without implementing their own resolver code. Running multiple DNSSEC implementations on a system seems like an unlikely path to greater security, so it would be good to get this right.

The glibc project has not yet chosen a path by which it intends to get things right, though some sort of annotation in /etc/resolv.conf looks like a likely outcome. Any such change would then have to get into a release; given the conservative nature of glibc development, it may already be late for the 2.23 release, which is likely to happen in February. So higher DNSSEC awareness in glibc may not happen right away, but there is at least some movement in that direction.

Comments (33 posted)

The proposed Trans-Pacific Partnership agreement (TPP) is a free-trade agreement negotiated by a number of countries that comprise approximately 40% of the global economy. Its stated purpose is to reduce barriers to international trade. A number of public-interest groups have raised concerns about the TPP; for example, the Free Software Foundation has expressed concerns about software freedom in imported consumer devices under the agreement. While some of the concerns that have been aired are more realistic than others, the agreement as a whole is indeed worrisome.

The problematic sections include Article 14.17, which directly mentions source code, Article 18.63, which extends copyright duration in many countries, Article 18.68, which deals with Technological Protection Measures, and Chapter 28, which provides that non-compliant signatory governments can face arbitration against (and a potential damage payout to) a complaining corporation.

The FSF's worries center around Article 14.17, which begins with:

No Party shall require the transfer of, or access to, source code of software owned by a person of another Party, as a condition for the import, distribution, sale or use of such software, or of products containing such software, in its territory.

However, this restriction is greatly limited according to the following section, which states that this restriction on government power "is limited to mass-market software or products containing such software and does not include software used for critical infrastructure". The clause is further watered-down by another article in the TPP, which specifically notes that government procurement is excluded from the application of this article.

Section 3(a) of the article states "commercially negotiated contracts" are another exception to the restrictions of this article. Copyleft licenses, however, are not contracts; Eben Moglen stated this in 2001 in an essay published by the FSF. Some worry that Section 3(a) may thus make copyleft unenforceable in TPP signatory states. However, copyleft-enforcement litigation is not affected by this section and would thus remain the same under the TPP.

In particular, this article refers to prohibitions on compelling source code release, but a copyleft enforcer will completely sidestep this issue by focusing entirely on copyright law itself. Should, say, an imported smartphone not come with source code for its GPL-licensed software, nor an offer for such source code, the copyleft enforcer would argue that the company producing the smartphone is not in compliance with copyright law, and can either choose to disclose source code or lose its rights to use, modify, and redistribute the software. As has been the standard approach for copyleft enforcement in the past and present. (See this post on the Software Freedom Conservancy site for more on license enforcement).

Nonetheless, this article remains a concern, because governments would be unable to require source code disclosure for any class of imported mass-market, consumer devices. Imported routers, personal health care devices (such as blood-testing devices for diabetics), and, to think of a recent example, embedded automotive software could not be required to come with source code.

Article 18.63, which extends copyright duration by 20 years in countries like Canada, has been rightly criticized by a number of academics as harming the economy and stunting the growth of the public domain. In an article published earlier this month, Canadian law professor Michael Geist notes that this clause is projected to cost Canadians "hundreds of millions" of dollars in lost savings on artistic works in addition to impoverishment of the artistic commons.

Turning to Article 18.68, all parties to the agreement would be required to implement strong penalties for digital rights management (DRM) circumvention, including the manufacturing, importing, and distributing of circumvention tools. One clause states: "Each Party shall provide for criminal procedures and penalties to be applied if any person is found to have engaged wilfully and for the purposes of commercial advantage or financial gain in any of the above activities." For those DRM-circumvention offenses that don't lead to criminal penalties, individuals would face civil penalties and the liability to pay potentially high damage awards to the rights holder. However, governments would also be given the option to grant exceptions to these penalties "in order to enable non-infringing uses if there is an actual or likely adverse impact of those measures on those non-infringing uses, as determined through a legislative, regulatory, or administrative process in accordance with the Party’s law". These exceptions could be codified in copyright law: for example, Section 1201 of the United States's Digital Millenium Copyright Act already specifies a few exemptions from the prohibition on DRM-circumvention, including encryption research.

Despite this potential mitigating clause, this entire article is problematic for open-source software developers and for Linux distributions. For example, the libdvdcss library, which allows playback of encrypted DVDs on Linux systems, could not be packaged for a commercial Linux distribution in a TPP state, and potentially not on any Linux distributions at all. While Debian, Fedora, and Ubuntu do not include libdvdcss, niche distributions like Puppy Linux and XBMC Live (who may feel that they can get away with it as they're small, non-commercial projects) as well as the popular Linux Mint do. Including one of those distributions in a Linux live DVD included as a promotion with a Linux magazine could lead one to potential criminal liability. This article further excludes the open-source world from enjoying media locked behind encryption and digital restrictions by codifying those restrictions and forcing them on a large part of the global economy.

Also troubling as a whole is Chapter 28, the "Dispute Settlement" chapter. This provides for penalties, including monetary damages, for signatories who do not adequately implement the TPP. A corporation can bring a signatory government in front of an arbitration panel to seek these penalties and a damage award. This type of dispute resolution process has been criticized by non-profit organizations such as the Council of Canadians for allowing "transnational corporations to challenge democratically-elected national governments and be paid compensation if public interest legislation is passed that affect future corporate profits."

While the above articles remain problematic, it's important to keep in mind that this agreement remains a proposal. Countries would still have to sign it, ratify it, and make changes to their domestic legislation to implement this agreement. However, there is not much time left for Americans to oppose the bill. President Barack Obama was given fast-track authority this past June to accelerate the implementation of TPP. There are now less than ninety days before this bill could be ratified by Congress. With the United States being the major force behind the TPP, its ratification of the agreement would virtually guarantee the other parties would follow step, leaving 40% of the world's economy bound by its problematic clauses.

Comments (9 posted)

November 26 is the US Thanksgiving holiday, an affair that generally involved the consumption of so much food that even lifting hands to the keyboard becomes impossible. Thus, according to tradition, LWN will not be publishing a Weekly Edition the week of the 26th. We'll put out some content over the course of the week as our digestion allows, and will return in force with the December 3 Edition. Our best wishes to go all of our readers as the holiday season gets underway.

Comments (3 posted)