Home » Blog » Categories » News

News

CppCon 2018: Spectre: Secrets, Side-Channels, Sandboxes, and Security--Chandler Carruth

By Adrien Hamelin | Sep 5, 2019 11:46 AM | Tags: community

We’re in the final countdown to this year’s CppCon, which starts on September 16. To whet your appetite for this year’s conference, here’s another of the top-rated talks from last year. Enjoy – and register today for CppCon 2019!

Spectre: Secrets, Side-Channels, Sandboxes, and Security

by Chandler Carruth

Summary of the talk:

The discovery of speculative execution side-channel attacks (called "Spectre") fundamentally changes the security model of every modern superscalar microprocessor. Extracting secret data (credit cards, cryptographic keys) through side-channels is not new and has challenged the cryptographic community for decades. Despite this, the industry has often been complacent in our response, viewing these attacks as impacting a tiny amount of code and being nearly impossible to weaponize. But speculative execution attack techniques have fundamentally altered the ease and applicability of side-channels, making them a serious threat to computer security. Responding to these issues has impacted CPU design, compiler design, library design, sandbox techniques and even the C++ programming language and standard.

This talk will explain how these kinds of attacks work at a high level and provide a clear set of terminology to describe these classes of vulnerabilities and attacks. It will show how the different variants work at the low level of modern hardware to give a detailed and precise understanding of the mechanics involved on CPUs today.

It will also provide guidance about what makes applications and services vulnerable and how to analyze your software to understand the degree of its exposure. It will include an overview of the numerous different mitigation techniques available, how to deploy them, and what tradeoffs come with them. Some of these mitigations will be covered in detail: how they work at a hardware level, where they don't work, and what attack vectors remain.

Finally, the talk will show how traditional side-channel risks are made substantially easier to exploit due to speculative execution. This will cover how cryptographic and other libraries dealing in high-value secrets need to be adapted to correctly defend against these attacks. Further, it will introduce general problems of sandboxing untrusted code from secret data and the current best techniques in those circumstances.

This talk will be accessible to most C and C++ programmers. No deep background on CPUs, assembly, hardware instructions, Spectre, side-channels, or security is needed.

Quick Q: How do C++ class members get initialized if I don't do it explicitly?

By Adrien Hamelin | Sep 5, 2019 11:41 AM | Tags: basics

Quick A: default constructors are called if available, otherwise there is no initialisation.

Recently on SO:

How do C++ class members get initialized if I don't do it explicitly?

In lieu of explicit initialization, initialization of members in classes works identically to initialization of local variables in functions.

For objects, their default constructor is called. For example, for std::string, the default constructor sets it to an empty string. If the object's class does not have a default constructor, it will be a compile error if you do not explicitly initialize it.

For primitive types (pointers, ints, etc), they are not initialized -- they contain whatever arbitrary junk happened to be at that memory location previously.

For references (e.g. std::string&), it is illegal not to initialize them, and your compiler will complain and refuse to compile such code. References must always be initialized.

So, in your specific case, if they are not explicitly initialized:

    int *ptr;  // Contains junk
    string name;  // Empty string
    string *pname;  // Contains junk
    string &rname;  // Compile error
    const string &crname;  // Compile error
    int age;  // Contains junk

fixing c++ with epochs -- Vittorio Romeo

By Vittorio Romeo | Sep 3, 2019 11:25 AM | Tags: None

This article proposes a mechanism to allow seemingly backwards-incompatible changes to C++'s syntax while actually maintaining backwards compatibility, leveraging the isolation of upcoming module units. The idea is similar to Rust's "Editions" mechanism. The post explains how the feature would work and how C++ would benefit from it.

fixing c++ with epochs

by Vittorio Romeo

From the article:

Imagine that you have been designing a programming language for over 30 years and that it gradually became widely used across the globe. Some of the decisions you made at the beginning were excellent and contributed to the success of your project. Some others, however, were not the best: over the years you and your users realized that the world would have been a better place if those choices you made eons ago were slightly different. [...]

What if I told you that I could fix all of your problems? Even better, what if I told you that backward-compatibility will never be broken and that migration to newer versions of your language could be automated?

CppCon 2018: Applied Best Practices--Jason Turner

By Adrien Hamelin | Sep 2, 2019 11:21 AM | Tags: community

We’re in the final countdown to this year’s CppCon, which starts on September 16. To whet your appetite for this year’s conference, here’s another of the top-rated talks from last year. Enjoy – and register today for CppCon 2019!

Applied Best Practices

by Jason Turner

Summary of the talk:

What happens when we start a project from scratch and try to apply all of the best practices? How well do constexpr, noexcept, [[nodiscard]] and other features interact with each other? Is it possible to apply all of the best practices at once, or will they conflict with each other? We will explore current best practices and examine their impact on compile time, runtime and testing. We'll also see some of the unexpected effects that result when best practices are applied to a new project.

Sourcetrail 2019.3 released -- Eberhard Gräther

By egraether | Aug 31, 2019 12:19 PM | Tags: None

Sourcetrail is a cross-platform Visual Source Explorer based on LLVM/Clang

<img alt="" data-cke-saved-src="https://www.sourcetrail.com/blog/images/release_2019_3/composition_trail.png" src="https://www.sourcetrail.com/blog/images/release_2019_3/composition_trail.png" 2638px;="" height:="" 1634px;"="" style="height: 142px; width: 230px; float: right;">

Sourcetrail 2019.3 released

by Eberhard Gräther

From the article:

The Sourcetrail 2019.3 release introduces the new Custom Trail dialog to query and display connections between any two symbols. Additionally, the new release brings Precompiled Header (PCH) Support for C and C++ projects to speed up the indexing step.

CppCon 2018: Simplicity: Not Just For Beginners--Kate Gregory

By Adrien Hamelin | Aug 30, 2019 12:27 PM | Tags: community

We’re in the final countdown to this year’s CppCon, which starts on September 16. To whet your appetite for this year’s conference, here’s another of the top-rated talks from last year. Enjoy – and register today for CppCon 2019!

Simplicity: Not Just For Beginners

by Kate Gregory

Summary of the talk:

Many people say that simple code is better code, but fewer put it into practice. In this talk I’ll spend a little time on why simpler is better, and why we resist simplicity. Then I’ll provide some specific approaches that are likely to make your code simpler, and discuss what you need to know and do in order to consistently write simpler code and reap the benefits of that simplicity.

CppCon 2018: The Bits Between the Bits: How We Get to main()--Matt Godbolt

By Adrien Hamelin | Aug 29, 2019 10:06 AM | Tags: community

We’re in the final countdown to this year’s CppCon, which starts on September 16. To whet your appetite for this year’s conference, here’s another of the top-rated talks from last year. Enjoy – and register today for CppCon 2019!

The Bits Between the Bits: How We Get to main()

by Matt Godbolt

Summary of the talk:

When you run your C++ code, have you ever considered how the linker, loader, operating system, C and C++ runtime all work so hard to get everything set up for you to start running your code in main()?

In this Linux-focused talk, Matt will talk about how the linker stitches together your code and how that fits in with dynamic linking. He'll touch on debugging issues with the loader, and how ODR violations can manifest themselves. Then he'll take a look at what's going on behind the scenes to get the C runtime up, and then the C++ runtime, along with all the global object constructors - showing more reasons why you shouldn't be using them!

By the end of the talk you should have an understanding of how a bundle of object files are brought together by the linker, along with the relevant runtimes, and then loaded and executed by the operating system.