David Chisnall

Photo by Will Harwood

Address University of Cambridge
William Gates Building
15 JJ Thomson Avenue
Cambridge CB3 1FD
United Kingdom
Office: GE10, William Gates Building
Telephone: +44 (0)1223 763 776
Fax: +44 (0)1223 334 678
E-mail: David.Chisnall AT cl.cam.ac.uk

Research Interests

  • Cross-language interoperability
  • Architectures for modern programming languages
  • Dynamic Object Oriented Programming Languages
  • Domain and Problem Specific Languages
  • Compiler design
  • Optimising ‘slow’ programming languages
  • High-performance garbage collection
  • Safety in unsafe languages

Teaching responsibilities

Open source work

Other interests

  • Argentine tango, Cuban salsa
  • Ultimate frisbee

Recent Publications

A full list is available on the publications page.

  1. L. Simon, D. Chisnall and R. Anderson. What You Get is What You C: Controlling Side Effects in Mainstream C Compilers. 2018 IEEE European Symposium on Security and Privacy (EuroS&P), (2018), 1–15. [doi]
      author = {Simon, L. and Chisnall, D. and Anderson, R.},
      booktitle = {2018 IEEE European Symposium on Security and Privacy ({EuroS\&P})},
      title = {What You Get is What You {C}: Controlling Side Effects in Mainstream {C} Compilers},
      year = {2018},
      pages = {1-15},
      keywords = {C++ language;cryptographic protocols;optimisation;program compilers;program verification;security properties;compiler commands;cryptographic protocol security;compiler performance;language security;mainstream C compilers;security engineers;careful programmer;cryptographic algorithm;compiler writers;compiler upgrade;timing channel;secure code;compiler optimization;implicit properties;crypto code;side effects;CPUs;Cryptography;Program processors;Standards;Libraries;Timing;Optimization;compilers;LLVM;Clang;compiler optimizations;side channels;cryptography;side effects;C;C abstract machine;constant-time;zeroing;erasing;stack},
      doi = {10.1109/EuroSP.2018.00009},
      month = apr

    Abstract: Security engineers have been fighting with C compilers for years. A careful programmer would test for null pointer dereferencing or division by zero; but the compiler would fail to understand, and optimize the test away. Modern compilers now have dedicated options to mitigate this. But when a programmer tries to control side effects of code, such as to make a cryptographic algorithm execute in constant time, the problem remains. Programmers devise complex tricks to obscure their intentions, but compiler writers find ever smarter ways to optimize code. A compiler upgrade can suddenly and without warning open a timing channel in previously secure code. This arms race is pointless and has to stop. We argue that we must stop fighting the compiler, and instead make it our ally. As a starting point, we analyze the ways in which compiler optimization breaks implicit properties of crypto code; and add guarantees for two of these properties in Clang/LLVM. Our work explores what is actually involved in controlling side effects on modern CPUs with a standard toolchain. Similar techniques can and should be applied to other security properties; achieving intentions by compiler commands or annotations makes them explicit, so we can reason about them. It is already understood that explicitness is essential for cryptographic protocol security and for compiler performance; it is essential for language security too. We therefore argue that this should be only the first step in a sustained engineering effort.

  2. David Chisnall. C is Not a Low-level Language. Commun. ACM 61, 7 (2018), 44–48. [doi]
      author = {Chisnall, David},
      title = {C is Not a Low-level Language},
      journal = {Commun. ACM},
      issue_date = {July 2018},
      volume = {61},
      number = {7},
      month = jun,
      year = {2018},
      issn = {0001-0782},
      pages = {44--48},
      numpages = {5},
      url = {https://queue.acm.org/detail.cfm?id=3212479},
      doi = {10.1145/3209212},
      acmid = {3209212},
      publisher = {ACM},
      address = {New York, NY, USA}

    Abstract: Your computer is not a fast PDP-11.

  3. Alexandre Joannou, Jonathan Woodruff, Robert Kovacsics, Simon. W. Moore, Alex Bradbury, Hongyan Xia, Robert N. M. Watson, David Chisnall, Michael Roe, Brooks Davis, Edward Napierala, John Baldwin, Khilan Gudka, Peter G. Neumann, Alfredo Mazzinghi, Alex Richardson, Stacey Son and A. Theodore Markettos. Efficient Tagged Memory. 2017 IEEE International Conference on Computer Design (ICCD), (2017), 641–648. [pdf] [doi]
      author = {Joannou, Alexandre and Woodruff, Jonathan and Kovacsics, Robert and Moore, Simon. W. and Bradbury, Alex and Xia, Hongyan and Watson, Robert N. M. and Chisnall, David and Roe, Michael and Davis, Brooks and Napierala, Edward and Baldwin, John and Gudka, Khilan and Neumann, Peter G. and Mazzinghi, Alfredo and Richardson, Alex and Son, Stacey and Markettos, A. Theodore},
      booktitle = {2017 IEEE International Conference on Computer Design (ICCD)},
      title = {Efficient Tagged Memory},
      year = {2017},
      pages = {641-648},
      keywords = {Computer architecture;Error correction codes;Hardware;Metadata;Pipelines;Random access memory;Security;Caches;Memory;Processor;Safety;Security},
      doi = {10.1109/ICCD.2017.112},
      pdf = {http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201711-iccd2017-efficient-tags.pdf},
      issn = {1063-6404},
      month = nov

    Abstract: We characterize the cache behavior of an in-memory tag table and demonstrate that an optimized implementation can typically achieve a near-zero memory traffic overhead. Both industry and academia have repeatedly demonstrated tagged memory as a key mechanism to enable enforcement of powerful security invariants, including capabilities, pointer integrity, watchpoints, and information-flow tracking. A single-bit tag shadowspace is the most commonly proposed requirement, as one bit is the minimum metadata needed to distinguish between an untyped data word and any number of new hardware enforced types. We survey various tag shadowspace approaches and identify their common requirements and positive features of their implementations. To avoid non-standard memory widths, we identify the most practical implementation for tag storage to be an in-memory table managed next to the DRAM controller. We characterize the caching performance of such a tag table and demonstrate a DRAM traffic overhead below 5% for the vast majority of applications. We identify spatial locality on a page scale as the primary factor that enables surprisingly high table cache-ability. We then demonstrate tag-table compression for a set of common applications. A hierarchical structure with elegantly simple optimizations reduces DRAM traffic overhead to below 1% for most applications. These insights and optimizations pave the way for commercial applications making use of single-bit tags stored in commodity memory.

  4. David Chisnall, Brooks Davis, Khilan Gudka, David Brazdil, Alexandre Joannouand Jonathan Woodruff, A. Theodore Markettos, J. Edward Maste, Robert Norton, Stacey Son, Michael Roe, Simon W. Moore, Peter G. Neumann, Ben Laurie and Robert N. M. Watson. CHERI JNI: Sinking the Java security model into the C. Proceedings of the Twenty Second International Conference on Architectural Support for Programming Languages and Operating Systems, ACM (2017), 569–583. [pdf] [doi]
      author = {Chisnall, David and Davis, Brooks and Gudka, Khilan and Brazdil, David and Woodruff, Alexandre Joannouand Jonathan and Markettos, A. Theodore and Maste, J. Edward and Norton, Robert and Son, Stacey and Roe, Michael and Moore, Simon W. and Neumann, Peter G. and Laurie, Ben and Watson, Robert N. M.},
      title = {{CHERI JNI}: Sinking the Java security model into the {C}},
      booktitle = {Proceedings of the Twenty Second International Conference on Architectural Support for Programming Languages and Operating Systems},
      series = {ASPLOS '17},
      year = {2017},
      location = {Xi'an, China},
      publisher = {ACM},
      address = {New York, NY, USA},
      acmid = {3037725},
      pages = {569--583},
      numpages = {15},
      isbn = {978-1-4503-4465-4},
      keywords = {Java language, C language, bounds checking, capabilities, compilers, memory protection, memory safety, processor design, security},
      pdf = {http://dl.acm.org/authorize?N24950},
      url = {http://doi.acm.org/10.1145/3037697.3037725},
      doi = {10.1145/3037697.3037725}

    Abstract: Java provides security and robustness by building a high-level security model atop the foundation of memory protection. Unfortunately, any native code linked into a Java program – including the million lines used to implement the standard library – is able to bypass both the memory protection and the higher-level policies. We present a hardware-assisted implementation of the Java native code interface, which extends the guarantees required for Java’s security model to native code.

    Our design supports safe direct access to buffers owned by the JVM, including hardware-enforced read-only access where appropriate. We also present Java language syntax to declaratively describe isolated compartments for native code.

    We show that it is possible to preserve the memory safety and isolation requirements of the Java security model in C code, allowing native code to run in the same process as Java code with the same impact on security as running equivalent Java code. Our approach has a negligible impact on performance, compared with the existing unsafe native code interface. We demonstrate a prototype implementation running on the CHERI microprocessor synthesized in FPGA.

  5. Robert N. M. Watson, Robert M. Norton, Jon Woodruff, Simon W. Moore, Peter G. Neumann, Jon Anderson, David Chisnall, Brooks Davis, Ben. Laurie, Michael Roe, Nirav H. Dave, Khilan Gudka, Alexandre Joannou, A. Theodore Markettos, J. Edward Maste, Steven J. Murdoch, Colin Rothwell, Stacey D. Son and Munraj Vadera. Fast Protection-Domain Crossing in the CHERI Capability-System Architecture. IEEE Micro 36, 5 (2016), 38–49. [doi]
      author = {Watson, Robert N. M. and Norton, Robert M. and Woodruff, Jon and Moore, Simon W. and Neumann, Peter G. and Anderson, Jon and Chisnall, David and Davis, Brooks and Laurie, Ben. and Roe, Michael and Dave, Nirav H. and Gudka, Khilan and Joannou, Alexandre and Markettos, A. Theodore and Maste, J. Edward and Murdoch, Steven J. and Rothwell, Colin and Son, Stacey D. and Vadera, Munraj},
      journal = {IEEE Micro},
      title = {Fast Protection-Domain Crossing in the CHERI Capability-System Architecture},
      year = {2016},
      volume = {36},
      number = {5},
      pages = {38-49},
      keywords = {Capability engineering;Memory management;Program processors;Reduced instruction set computing;Systems modeling;CHERI;ISA;capabilities;capability;capability system;compartmentalization;hardware;instruction set architecture;memory management unit;memory protection;processor;security;software;vulnerability mitigation},
      doi = {10.1109/MM.2016.84},
      issn = {0272-1732},
      month = sep

    Abstract: Capability Hardware Enhanced RISC Instructions (CHERI) supplement the conventional memory management unit (MMU) with instruction-set architecture (ISA) extensions that implement a capability system model in the address space. CHERI can also underpin a hardware-software object-capability model for scalable application compartmentalization that can mitigate broader classes of attack. This article describes ISA additions to CHERI that support fast protection-domain switching, not only in terms of low cycle count, but also efficient memory sharing with mutual distrust. The authors propose ISA support for sealed capabilities, hardware-assisted checking during protection-domain switching, a lightweight capability flow-control model, and fast register clearing, while retaining the flexibility of a software-defined protection-domain transition model. They validate this approach through a full-system experimental design, including ISA extensions, a field-programmable gate array prototype (implemented in Bluespec SystemVerilog), and a software stack including an OS (based on FreeBSD), compiler (based on LLVM), software compartmentalization model, and open-source applications.