One of the main reasons of low TPM adoption is that interfacing with TPMs is quite hard: there are competing TPM software stacks, lack of key format standardization and many operating systems are not set up from the start to make TPM easily available (TPM device file is owned by root or requires privileged group for access). Even with a proper software stack the application may have to deal with low-level TPM communication protocols, which are hard to get right.

In this presentation we will explore a better integration of TPMs with some Linux Kernel subsystems, in particular: kernel keystore and cryptographic API. We will see how it allows the Linux Kernel to expose hardware-based security to third party applications in an easy to use manner by encapsulating the TPM communication complexities as well as providing higher-level use-case based security primitives.

Talk (60 min)

TPMs and the Linux Kernel: unlocking a better path to hardware security

Security

Platform

Talk (30 min)

DOOM in Space

Space

Complimentary food and drinks will be served. 

Conference reception with food and drinks

Demoscene: The Golden Years – Anders Norås


Step into the time machine and journey back to the vibrant era of the 1990s with Anders Norås as he delves into the genre defining era of the 16-bit demoscene.


Recently I got the opportunity to help the European Space Agency play DOOM on a Satellite. This short talk is an overview of how that happened, the code used and the challenges we faced.

Talk (220 min)

NDC Party

Cache friendly data + functional + ranges = ❤️

Technique

But C++ has evolved considerably since then and, despite what you might have heard, mostly in ways that make it safer and simpler to use.

This talk takes us on a tour of the evolution of C++ - from it’s genesis, following the PhD thesis of Bjarne Stroustrup - up to “modern” C++20 and C++23 - and a look ahead at what C++26 and beyond may bring.

The question is: is it too late to prevent C++’s decline into being “the next Cobol”?

Not your GrandParent’s C++

Language

In this talk, we explore a number of C++ Core Guidelines and other best practices and compare them to the form in which they have appeared in actual project style guides. We will compare the original intent to the effect of their application in those instances. In the end, we will draw conclusions how guidelines should be chosen and applied to projects to get the most benefit out of them without bogging the team down with needless bureaucracy.

Core and other guidelines. The good, the bad, the... questionable?

These topics have been quite popular in the C++ community for the last five years or so. However, many of them are focused on theoretical parts, have only small non-related examples, or even use other programming languages to illustrate the ideas.

This talk is prepared based on more than one year of using functional programming approaches for developing one of the commercial internal libraries our team is working on. I’m going to share this experience with the audience. We’ll talk about API design in general, spitting between pure and impure context, and the pros and cons of using “optional” and “expected”. There will be real code examples and some useful tips.

This talk will be useful for software engineers who want to start using monadic operations in their everyday routine or for those who already do it (at least partially) and want to learn more about that.

Monadic Operations in Modern C++: A Practical Approach

Path coverage in gcc

Tools

Reflection/injection - facilities for extracting information from the program, performing compile-time computations based on that information, and injecting new program entities based on those computations.

Pattern matching - a new expressive selection mechanism that matches values against patterns and binds variables when matches are successful.

Senders - a framework for asynchronous programming that enables us to write generic code that can run on any type of execution resource, from a single thread to a cluster of GPUs.

Come to this talk to find out what's on the horizon for C++, how it will change how you code, and why you should be excited about it.

C++ Horizons

Sharing data in multi-thread programming may be tricky and there are plenty of options on how to deal with it. You should always go for the simplest possible scenario to not end up in trouble.
In this talk we will build up the whole story from illustrative examples which will allow us to understand all synchronization primitives available from C++ 20. We will also uncover what the memory model is and why we need it.

At the end, you should be able to spot problematic code parts, easily decide which synchronization technique to use and reason about it.

This session will be mostly about examples with all different synchronization primitives with a brief introduction to memory model theory. For a complex understanding of the topic I highly recommend attending the previous session in the same room "The Two Memory Models" by Anders Schau Knatten where you will get a solid theoretical background about memory model problematics.

Memory Model: Get your shared data under control

Dependency Injection (DI) is a design pattern fostering loosely coupled code by separating components from their dependencies. We'll delve into various DI types in C++, such as constructor, setter, interface, and template injection, exploring their use cases and best practices.

Despite C++ lacking native reflection support, we can achieve dynamic analysis and manipulation of class structures through introspection techniques like type traits, constexpr functions, and variadic templates. Template metaprogramming, complemented by features like SFINAE and type deduction, extends the capabilities for introspection and reflection.

Furthermore, we'll examine how the fusion of Dependency Injection and Reflection can facilitate extensible and adaptable software architectures. Leveraging libraries to simulate reflection and dynamically resolve dependencies enables a more flexible DI setup, easing the integration of new components into existing systems.


Exploring Dependency Injection and Reflection in Modern C++

My favorite (constexpr) data structures

In this talk, I aim to unravel the complexities of process address space using the Linux kernel as an example.

Demystifying Process Address Space: Heap, Stack, and Beyond

That’s what we thought in 2012 when we started Pexip. Based on our experience of building physi- cal telepresence devices and dedicated server products, our goal was to build and sell a virtualised, distributed, videoconferencing system to big companies. A video equivalent of a telephone exchange. Because we would be delivering product to customers, not running a service in the cloud, we would have all the additional constraints which that brings.

This talk will examine our experiences during that twelve year journey from inception through stock market launch to maturity. It will also draw on my previous, less successful, forays into the startup world.

This is not a talk focusing on language choice or the benefits of one development methodology over another. We are going to look at some of problems involved in building a software product and try to arrive at a consistent approach to resolving them. We’ll discover that there were good reasons behind many of those annoying choices.

Even though we won’t all get, or want, the opportunity to start with a clean slate, taking that thought experiment into a mature product development group can provide insights and benefits.

A Clean Slate

Product

And in many cases applications requiring sensor processing can be solved faster and better using machine learning techniques. This talk explains the why and how to use machine learning on microcontrollers.

Using machine learning to save power and development time

The main body of the workshop will comprise running Cosmic Ray on a provided project. This will ensure that we can see all of the important elements of the system while avoiding the complexities of working with unknown code bases. With that said, if you want to try running Cosmic Ray on your own code as well, we can try that, too.

If time permits, we can also look at topics like creating new mutation operators and integrating Cosmic Ray into continuous build systems. Ideally, we’ll work through the main portion of the workshop with enough time for students to explore Cosmic Ray on their own, so come prepared to experiment and explore!

Mutation Testing in Python with Cosmic Ray

Testing

Python

In the first part of this talk, we review some examples of C/C++, both single- and multithreaded, including a common lock-free algorithm. We examine the compiler-generated Assembly code and gain an intuition for how much reordering the compiler and the CPU are allowed to do. We then discuss what C++ means by a data race and how to avoid them using atomics and memory orderings like sequentially consistent, relaxed, acquire, and release. We also see how C++ reasons about memory ordering in terms of happens-before relationships.

In the second part of the talk, we examine the CPU memory models and what we mean by reordering of memory operations. There are many sources of reordering, such as the compiler, the CPU pipeline, micro-ops, memory systems with store buffers and coalescing, caches, etc. We then see how CPUs reason about memory ordering differently than languages like C++ and Rust and how the CPU memory models enable the language memory models to work. We also see how x86, ARM, and RISC-V have different approaches to this.

At the end of this talk, you will have gained a better understanding of what guarantees your programming language gives you and how the CPU works under the hood to allow your programs to (safely) go vroom! You will also have learned not to make assumptions about the correctness of your code by simply looking at the Assembly code.

PS! In the next slot in the same room, Jana Machutová will go more into practical applications of the memory model in C++ with her talk "Memory Model: Get your shared data under control".

The Two Memory Models

As software developers, one of our tasks is to ensure intuitive operation - regardless of the language the user (or compiler) understands best. Otherwise, the risk of errors increases and operational safety may no longer be guaranteed.

National language adaptations - possibly dynamically at runtime - appear to be a solved problem area. There are libraries for this. However, if you want to use them together with std::format or std::print, you will realise that none of them allow translation at runtime, because the format strings must be C++ literals! The compiler analyses these during program translation in order to detect errors in the use of formatting instructions and argument types. This is one of the main advantages of std/fmt formatting over the other options, which only detect errors during runtime!

I am currently developing a library for our company's machines that allows error detection at translation time, but still allows dynamic translation into the user's preferred language.

Human languages do not always follow immediately recognisable rules, e.g. when it comes to the correct choice of a linguistic form in connection with statements about several things. The Unicode Standard describes such rules in machine-readable form, which the library uses to provide the correct translation.

For the implementation of the library, it is crucial to convert known idioms from the programming of runtime code into semantically correct equivalent code for execution at translation time. Despite 'constexpr', some code looks unfamiliar at first when it is translated into the language of execution at compile time.

In the course of the presentation we will therefore talk about:

a widely used system for language translation

existing libraries for this and their APIs or embedding in the build process

differences and similarities of code execution at runtime and translation time

the 'language rules' for translation between the two

Code excerpts from my library serve to illustrate the points mentioned.

Not getting lost in translations

This talk describes the problems with this approach and a better approach for achieving safety and portability.

Correct Use of Integers in Safety-critical Systems

Topics to be covered:
1) How software development has changed over the years
2) How software development is the same 45 years on
3) The importance of testing at various integration levels
4) What we learn from disasters and near-misses
5) Why spacecraft software has to be "better" than other embedded software
6) The future of embedded software as it relates to human-rated spacecraft
7) Pictures, videos and other interesting tidbits of Shuttle and Orion flights
8) Questions answered

Contrasting Embedded Software Development for the Space Shuttle and the Orion MPCV

Beyond introducing Carbon's milestones, we'll share what we expect to get out of this release and what C++ developers can expect when using them. The talk will dive into the specific parts of Carbon's 0.1 milestone that are already shaping up and show how they are working in practice, including demos of the Carbon toolchain and compiling small, early, but working Carbon programs. We will also outline the remaining path to actually completing 0.1 and getting it into the hands of developers. And last but not least, we'll share a preview of the incremental evaluation and adoption workflow we are envisioning for existing C++ developers and codebases.

The Carbon Language: Road to 0.1

But despite their fundamental importance, there are some common misconceptions about them, in particular about several of the most often used design patterns:

The modern form of the Visitor design pattern, std::variant, is often considered a replacement of virtual functions.

The Decorator design pattern is sometimes mistaken as the Adapter design pattern.

The Chain of Responsibility design pattern is often confused with Decorators.

Explicit object parameters (“deducing this”) is often named as a modern, better form of CRTP.

In this talk I'll shed some light on these misconceptions and explain how to properly distinguish between the different
design patterns.

Design Patterns - The Most Common Misconceptions (2 of N)

Let’s see if and how the modern C++ tooling can address the things that frustrate C++ developers the most. We’ll cover things from package management, CI setups, and development environments, to CMake debug and profiling, and a bit of data flow analysis (DFA) to statically identify many sources of undefined behavior and potential vulnerabilities.

Keynote: How To Address 7 Major C++ Pain Points with Tools

Blueye was founded in 2015 and shipped its first model, the Blueye Pioneer, at the end of 2018. Since then, we have manufactured and delivered more than 1250 units to more than 60 countries for use in industries such as defence, search and rescue, aquaculture, environmental monitoring, and construction. In 2022, Blueye gained world attention by recording the first pictures of the damaged Nord Stream pipeline.

In this presentation, I will share Blueye’s experience building a robust, user-friendly, scalable hardware and software product
and the many lessons we have learned along the way. There will also be lots of underwater footage of marine life and wrecks.

This talk will touch on topics such as:
- The hardware and software architecture of the Blueye underwater drone
- How we develop, deploy, and update Blunux, our onboard operating system, using Yocto
- Design for manufacturing and automated hardware testing using OpenHTF
- Control system development in C++ and use of frameworks such as ROS2
- Exposing functionality through our onboard and remote SDKs
- Use of ZeroMQ and Protobuf as communication protocol and log format

Deep dive with Blueye underwater drones

Introduction to eBPF

These were the glory days where human ingenuity clashed with machine capabilities in a perpetual battle of digital creativity. In this lighting talk, attendees will be treated to a nostalgic exploration of the subculture's pinnacle, witnessing firsthand the relentless competition and boundless innovation that defined this epoch. Whether you're a seasoned enthusiast or completely new to the scene, prepare to be entertained and inspired by the timeless ingenuity and artistic fervor that characterized this era. Join us for a journey through time and witness the enduring legacy of creativity that still makes its marks on popular culture.

Demoscene: The Golden Years

Memory Safety:  Rust vs. C

Rust

Anders started programming in Turbo Pascal in 1995, and has been programming professionally in various languages since 2001. He's currently a principal engineer at Ascenium in Oslo, working on a new CPU design. He's also the author of the book C++ Brain Teasers, http://cppquiz.org, and https://blog.knatten.org

QUIZ

The good news is that naming well is a learned skill, and you can learn it, and start to name better right away. In this talk, I'll tell you why names matter, what benefits a good name can bring, and how to be better at naming. I'll discuss some categories of names and some common decisions within those categories. I'm not going to give you a set of rules to follow: this is about thinking and considering the meaning of the things you are naming. I will give you some questions to ask yourself and some structure that I use to help me to help those who read what I write.

I'll also address renaming things in existing (legacy) code, why and when to do it, and why getting it right the first time may not even be a realistic goal. You should be a lot more confident naming things after we spend this time together.

Naming is Hard: Let's Do Better

On the other side, this mechanism has been repeatedly used in various vulnerabilities and exploits as a starting attack vector, multiplying the damage and impact of these exploits. And since it became so popular within the offensive industry, many Linux distributions and security guidances started recommending disabling this feature altogether.

There is an ongoing debate whether unprivileged user namespaces provide more security or make the system more vulnerable. In this presentation we will review how user namespaces might help building sandboxed secure applications. But we will also show how a recently discovered Linux kernel bug turned into a security vulnerability just because user namespaces are available on the system. Finally, we will give recommendations on how to get the best of both worlds: allow well-behaved applications to utilize user namespaces for better security, while blocking the feature for potentially malicious users/code.

Linux user namespaces: a blessing and a curse

In this workshop I will show by means of an 'easy' example (Kata) how this can be achieved following a "Metal-In" TDD approach, which can be seen as a Dual-Target TDD specific implementation. This approach is aimed, among other things, to minimize how much hardware gets involved in our embedded code development workflow.

We will first touch the metal, facing its cold truth, till we finally Make-It-Work. Later, we will drive our code 'In', Making-It-Right (enough), while creating our own decoupled and portable entities and business domain model. We will do it safely, iteratively and incrementally,

• Develop a highly decoupled and portable ‘BatteryMonitor’
module following Metal-In TDD approach.
• Highlight the differences between the Make-It-Work phase
(TDD’s Red to Green phases) and the Make-It-Right (TDD’s
Refactor phase)
• Use state of-the-art automated refactoring tools available for
C/C++

Metal-In Test-Driven Development: A Dual-Target TDD approach

Under Linux, applications can pipe data in batches between sockets with the `splice()` syscall. However this is not the only way to splice two sockets together!

Linux also offers another way to push packets between two TCP sockets without exiting to user-space, called sockmap. The mechanism is powered by the built-in logic built in the core network stack and a couple of BPF-based components to drive the operation.

In this talk we will go over everything a user needs to know to get started using BPF sockmap. We will also discuss sockmap features, internal design, as well as its caveats and limitations.

Speedrun through Splicing Sockets with Sockmap

How To Use `constexpr` In C++23

For any software project, the potential presence of certain bugs is a cost-risk-benefit proposition. How much time can one spend to ensure catastrophic failure does not happen?

Property Based Testing (PBT) is a technique which seems to uncover many bugs compared to the effort needed. It can also be incorporated early in the development process which decreases the effort required to debug.

This presentation looks at the hypothesis property based testing tool used in our Scientific Computing team at Equinor. We look at how it compares to traditional testing methods and verification techniques, and how we use PBT in our team.


Omg, how do I write software that isn't a ticking timebomb!?

Remote blinky on nRF52 using Rust

All good? Unfortunately, not. The iterator concept, which we have been using since the advent of C++, is fundamentally flawed. In particular, some iterators must behave differently depending on whether they are meant to point at an element or at a boundary between elements. So elements and boundaries are really two distinct concepts. In this talk, I will convince you that the problem is real and has practical implications, make a proposal on how to fix it and show how the solution not only fixes the problem but makes for clearer code and prevents mistakes.


Why Iterators Got It All Wrong — and what we should use instead

When are objects created and when are they destroyed?
How does temporary lifetime extension come into play and what changed there recently?
What happens when you `std::malloc` memory and just pretend objects are there without creating anything?
Or worse: You use `mmap()` to read shared memory.
How do unions interact with constructors, strict aliasing, or the "common initial sequence"?
What when you explicitly call the destructor and later re-use the same storage?
What's the deal with `std::launder`, `std::bit_cast`, and `std::start_lifetime_as`?

We'll answer all of those questions and much more.
We'll do that by looking at the C++ standard, old and new proposals, and compiler optimizations.

An (In-)Complete Guide to C++ Object Lifetimes

We'll get a bird's eye view of the steps that we typically see in compilers as well as follow a piece of code through the pipeline to witness the transformations first hand:
From parsing to code generation, with a little bit of optimization sprinkled on top!

A bird's eye view of a compiler

What influences the rising energy consumption and is there something we can do about it? One not so obvious factor is the choice of which programming language is used to write the programs that are used all over the world.

In this talk we want to analyze how the different programming languages influence the energy consumption of the program. We are going to cite studies and do our own analysis using different programming languages, like C++, C#, Rust, Python and maybe more. Energy consumption is defined as run time multiplied by power consumption and our analysis will show the influence of choosing a different programming language for both components of energy consumption.

Green Programming

Are the regulators «out to get» C++? Will they stop here or will this get progressively more serious? Should we migrate to other languages? What does «memory safe» mean anyway? And why not just wait for C++ to become memory safe?

We’ll look at what has happened lately, why this might be happening and what is likely to happen next.

We’ll also look briefly at the feasibility of making C++ memory safe(ish), and if this could stop the pressure to migrate away from C++.

Finally, we’ll look at what languages one might consider migrating to, why that discussion invariably ends up mentioning Rust, and some things to consider if you want start migrating.

The existential threat against C++ and where to go from here

Beyond unit tests: A peek into large-scale automated testing of video conference systems.

We'll examine features of the toolchain and additional tools which can be used to create more secure applications and we'll look at system level features of Linux which will make your running system more robust. We'll also look at some of the kernel features which can be used to harden the system and review aspects of the boot process which can be used to secure the booting of the system.

Getting Started with Embedded Linux Security

Linux

Embedded

In this session we'll dive into this technology and some of its surrounding infrastructure - Magic Trace.
We will live debug and analyze a running application and discuss the merits of this approach versus some other more widely used tools.

The Magic of a Trace

In this talk I will dive into the choices we at Neat have made in our test architecture in order to both preserve and create value for our company, customers and software development teams. 

I will go through detailed, concrete choices in test code and move onward to the organization of frameworks, tools, processes and practices. I will cover the measures we have intentionally chosen in order to catch regressions, reduce false positives, write maintainable tests, understand test results and enable development teams to do their job faster and with increased confidence. While our specifics, embedded software and end-to-end tests written in Python may not match your situation, many of the questions we asked in order to determine the choices we have made are likely to be both relevant and perhaps even unthought for other teams. 

Test architecture encompasses everything from code to more theoretical concerns like enterprise architecture, but with concrete, immediate consequences. Ignore it at your peril or at least come and find out that it’s a rich, challenging and rewarding domain.

Test architecture is a real thing

For the last three years, we have been using vcpkg to build production packages of our libraries across various platforms and to share internal libraries within the company. Vcpkg has served us well for both, but we have discovered many pitfalls along the way. In this talk, I will show you how to avoid them, or at least how to dig yourself out after you've fallen in.


Using vcpkg in anger

How we came to love 🦀 Ferris: cargo cult or real need?
What is it like to come at Rust from two very different directions: C++ and C#? What are the gaps, the needs, the gems and the tools you should know about? Here's a real journey and the various experiments leading up towards the success stories at Microsoft.
Want to compare notes? Let's chat.


Unleashing 🦀 The Ferris Within

This talk will showcase how a single developer's simple crash analysis
side project got the investment needed to transform it into an
indispensable part of our continuous delivery process. By providing
effective communication from anyone to everyone around anything that
may fail, this tool helps us navigate through the labyrinth of defective
hardware batches, failing test pipelines, bad commits, cloud services
having a bad day, and a million potentially loose cables in hardware labs.


Crash and test failure analysis with AI... no wait, ehm, with regexes!

Despite being very powerful, these elements can sometimes lead to designs that trade-off performance gains for increased binary size. And although binary size is considered in most platforms a constraint-free resource, it can pose a great challenge for embedded development.

In this session, we explore some cases where fundamental C++ features and code designs run into foul with binary size and how we could analyze and better understand these trade-offs during development.

What if binary size matters?

Join me on the journey approaching zero dependency by writing and compiling an application that supports the BIOS-variant UEFI, allowing us to boot it on any compliant PC system / emulator (e.g. qemu).

Bootable applications - an introduction

This talk covers local reasoning principles and explores conventions and rules to support local reasoning and develop better interfaces and code.

Locknote: Local Reasoning in C++

What can you do to make both aging and programming more pleasant for yourself? How can you help the older people you know, and set up systems that will help you when you need it? When it comes to ensuring a pleasant and long old age, it's not too late -- and it's also never too soon.

The Aging Programmer

In this session, we walk through how to design a new language feature in an older language like C. We discuss technical constraints, existing implementations, user expectations, and ways to understand and handle the complexity of allowing for e.g. adding 2 "vec3"s together. We discuss algorithms for how to match arguments to functions, and ways to achieve this without the typical, potentially binary-bloating techniques that C++ or Rust have to deploy to get the same work done.

This feature does not currently exist in C, so this is an exercise in how to engage with designing under constraints (in this case, 50+ years of it) for software developers!

Hello Operator: Making The Call for C

The C++ onion as it relates to construction, destruction and polymorphism,

Order of Object construction & destruction, and pre- & post-main() processing.

Member Function Pointers (not your father’s C function pointer),

Member Data Pointers (not raw pointers) (data-morphic functionality),

Understanding the Call Stack, Stack Frames and Base Pointer mechanisms.

NDC { TechTown }

Agenda

09:00 - 10:00 (UTC+02)

Keynote: How To Address 7 Major C++ Pain Points with Tools

Anastasia Kazakova

10:20 - 11:20 (UTC+02)

Correct Use of Integers in Safety-critical Systems

Robert Seacord

Demystifying Process Address Space: Heap, Stack, and Beyond

Piotr Wierciński

My favorite (constexpr) data structures

Hana Dusíková

Design Patterns - The Most Common Misconceptions (2 of N)

Klaus Iglberger

Using machine learning to save power and development time

Eirik Midttun

11:40 - 12:40 (UTC+02)

Deep dive with Blueye underwater drones

Jonas Follesø

Exploring Dependency Injection and Reflection in Modern C++

Mikhail Svetkin

TPMs and the Linux Kernel: unlocking a better path to hardware security

Ignat Korchagin

Path coverage in gcc

Jørgen Kvalsvik

Not getting lost in translations

Daniela Engert

13:40 - 14:40 (UTC+02)

Cache friendly data + functional + ranges = ❤️

Björn Fahller

C++ Horizons

Bryce Adelstein Lelbach

Memory Safety: Rust vs. C

Robert Seacord

A Clean Slate

Giles Chamberlin

Introduction to eBPF

Martin Ertsås

15:00 - 16:00 (UTC+02)

Naming is Hard: Let's Do Better

Kate Gregory

Core and other guidelines. The good, the bad, the... questionable?

Arne Mertz

The Two Memory Models

Anders Schau Knatten

Monadic Operations in Modern C++: A Practical Approach

Vitaly Fanaskov

Not your GrandParent’s C++

Phil Nash

16:20 - 17:20 (UTC+02)

The Carbon Language: Road to 0.1

Chandler Carruth

Memory Model: Get your shared data under control

Jana Machutová

Mutation Testing in Python with Cosmic Ray

Austin Bingham

Contrasting Embedded Software Development for the Space Shuttle and the Orion MPCV

Darrel Raines

17:20 - 21:00 (UTC+02)

NDC Party

Anders Norås

Ólafur Waage

Anders Schau Knatten

18:30 - 19:00 (UTC+02)

Demoscene: The Golden Years

Anders Norås

19:15 - 19:45 (UTC+02)

DOOM in Space

Ólafur Waage

20:00 - 21:00 (UTC+02)

QUIZ

Anders Schau Knatten