David Chisnall

Most modern processors have a very simple idea of a pointer: an integer containing an address in memory. This representation is used by all of the architectures that are officially supported by LLVM. In this talk, we'll take a look at what's needed for architecture where it isn't the case.

The CHERI processor (see Security track talk for more detail) provides a capability-oriented model for addressing memory. All virtual addresses are accessed via a memory capability, an unforgeable token of authority that can be stored in registers or memory and grants rights to a region of memory. We want to use memory capabilities as pointers and to do this have had to teach LLVM that (some) pointers are not integers.

Fortunately, LLVM IR is agnostic to pointer representation. Unfortunately, various parts of the code make this assumption. In this talk, we'll take a look at some of the changes that were required in the target-agnostic parts of LLVM to allow us to write a hardware-enforced memory-safe C compiler.

The CHERI research CPU extends the 64-bit MIPS ISA with byte-granularity memory protection. CHERI enables language memory model enforcement and fault isolation in hardware rather than software. In contrast to past capability models, CHERI complements, rather than replaces, the ubiquitous page-based protection mechanism, providing a migration path towards deconflating data-structure protection and OS memory management. Furthermore, CHERI adheres to a strict RISC philosophy: it maintains a load-store architecture and requires only single-cycle instructions, and supplies protection primitives to the compiler, language runtime, and operating system.

This talk will present the CHERI softcore and associated software stack and describe how building on open source has enabled full-stack security research.

2014 saw memory safety vulnerabilities such as Heartbleed in the mainstream press on several times, yet modern CPUs provide a memory model that does nothing to prevent them. Modern security-critical applications such as web browsers split themselves into components to minimise the damage done by a compromise, but are forced to do so using hardware mechanisms (the MMU) designed to protect small numbers of programs from each other and which don't scale to the hundreds or thousands of components that modern software demands.

The CHERI research CPU was created to attempt to apply the RISC philosophy to addressing these problems: To provide a simple hardware primitive that could be used to enforce everything from object-granularity memory protection to library-granularity sandboxing, with the policy under the control of software. The resulting design has undergone several significant revisions and is the focus of ongoing research on OS and programming language security policies.

Our software stack uses a modified FreeBSD and LLVM/Clang, co-designed along with the CPU. This allows us to evaluate real programs, running at a useable (if not spectacular) speed.

Towards the very end of 2011, new versions of the C and C++ standards were released. The last time this happened was 1999 for C and 2003 for C++, so this is far from a regular occurrence. Much of the discussion of the support has focussed on the compiler, but both C and C++ have a large standard library. The C standard library is a core part of any UNIX system - the public system call interface is specified in terms of functions in this library - and so the task of bringing this support to users falls to a mixture of libc, the compiler, and a few other supporting pieces of code.

This talk will look at the current status of support for these new standards in FreeBSD, the difficulties of implementing some parts, how they overcome, and the remaining challenges.

This talk will give an overview of the level of dynamic behaviour that's possible with Étoilé, using a mixture of Objective-C and a Pragmatic Smalltalk. We will attempt to convince the audience that shipping statically compiled libraries and executables does not have to mean giving up the flexibility of a dynamic, Smalltalk-like, environment, complete with introspection and run-time code modification.

Compiling Smalltalk to fast native Code

FreeBSD 10 is expected to have a completely new C++ stack. The reasons for this are partly legal and partly technical. The existing stack is covered by version 2 of the GPL, but newer versions from upstream are GPLv3. The new C++11 standard means that shipping an old version of the GNU stack is no longer acceptable. This talk will cover the various parts that were required for replacing this stack, the challenges and missing pieces that needed implementing and the advantages of the new stack.

Most of the Free Software world currently uses the C++ stack provided by the GNU project, including the C++ front end to the GNU Compiler Collection and libstdc++, the GNU implementation of the C++ standard library. In 2007, these projects switched to version 3 of the GNU General Public License. As a result, newer versions have not been imported into FreeBSD and other projects with similar licensing conditions. GCC 4.2.1 and the associated libstdc++ release are the most recent that can be shipped with these platforms. Since this release, a new version of the C++ standard, C++11, has been published. This includes a number of significant changes to both the language and the standard library. Some, such as r-value references, allow much more efficient implementation of some fundamental parts of the standard template library and make a significant reworking - if not a complete rewrite - desirable. These two factors, the license and the need to support the new standard, made it desirable for FreeBSD to switch to a completely new C++ stack. This includes a variety of components. At the bottom sits the C++ runtime library, responsible for providing features such as exception handling and run-time type information. On top of this is the C++ standard library, which provides the classes that the standard mandates. None of this, of course, would be any use without a C++ compiler. This talk will examine each of the components in the new, permissively licensed, C++11 stack, including libcxxrt, libc++, clang / LLVM, and the modifications that were required to FreeBSD to support all of these. Some of these libraries required writing from scratch, while others required effort to port or integrate. They all depend on various features that are not specific to C++, some of which already existed and some of which required implementing from scratch.

With iOS 5 and OS X 10.7, Apple introduced a number of new Objective-C features. With the release of version 1.6 of the GNUstep Objective-C runtime and version 3.0 of clang these are now all available to GNUstep developers. The new features include better data hiding, automatic reference counting, and a number of other features. This talk will cover these features, as well as some of the extensions beyond Apple's version and the improvements in Objective-C performance since FOSDEM last year.