Blog

Panics in Rust by default unwind to run Drop implementations for all values on the stack. Rust's stack unwinding is implemented using the same mechanism as C++ exceptions on most platforms. Recently the Cranelift code generator got support for "landingpad" style exceptions as detailed in the corresponding Cranelift RFC allowing me to add support for unwinding on panics to rustc_codegen_cranelift (cg_clif) for Unix systems.

In this article, I'll show you how exception handling works in cg_clif by walking you through several layers of the compilation process all the way to the runtime behavior.

In part 1 of the "SIMD in zlib-rs" series, we've seen that, with a bit of nudging, autovectorization can produce optimal code for some problems.

But that does not always work: with SIMD clever programmers can still beat the compiler. This time we'll look at a problem where the compiler is not currently capable of using the SIMD capabilities of modern CPUs effectively.

Fuzz testing is incredibly useful: it has caught many a bug during the development of NTP packet parsing and gzip/bzip2 (de)compression.

But I've always been unsatisfied with the fuzzer being a black box. When it runs for hours and reports no issues, what do we actually learn from that? In ntpd-rs we've previously had a bug fly under the radar because the fuzzer just did not reach a large chunk of code. So, does my fuzzer actually exercise the code paths that I think it should?

Over the past couple of months we've been hard at work on libbzip2-rs, a 100% Rust drop-in compatible implementation the bzip2 compression and decompression functionality.

For this project, we used c2rust for the initial translation from the C code to a Rust implementation. The generated Rust code has now been cleaned up and made safe where possible. This post describes our experiences using c2rust for this project.

This article was authored by Jordy Aaldering and Folkert de Vries

Over the past couple of months, we teamed up with Bernard van Gastel and Jordy Aaldering at Radboud University's Software Energy Lab to measure nea's energy efficiency.

The NTP protocol is used by many devices to synchronize their system clocks. However, many devices use SNTP clients (Simple NTP) which are even more vulnerable to interference. As most (S)NTP packets are unauthenticated, they are vulnerable to spoofing, making it possible to change a device's time by manipulating (S)NTP packets.

In this blog, we discuss how (S)NTP packets can be forged to manipulate a device's system clock. Especially on the default SNTP client for many Linux systems, this turned out to be very easy. We will also discuss the consequences of such attacks, as well as how these attacks can be prevented.

As part of the development of our Precision Time Protocol implementation, Statime, we want to know how it performs compared to other implementations of PTP.

To figure this out, last April we visited VSL, the Dutch National Metrology Institute. There, we performed comparitive precision tests between Statime and Linux PTP.

While using a full-blown filesystem for storing your data in non-volatile memory is common practice, those filesystems are often too big, not to mention annoying to use, for the things I want to do. My solution?

I've been hard at work creating the sequential-storage crate. In this blog post I'd like to go over what it is, why I created it and what it does.