Comparing Alternatives to top Written in Rust
> Recently I aliased top to ytop. Then I became aware of bottom, and zenith. These are all terminal based system monitoring tools that you might use instead of top. In this post I set out to compare them.
How Tailscale works
> There is one last question that comes up a lot: given that Tailscale creates a mesh “overlay” network (a VPN that parallels a company’s internal physical network), does a company have to switch to it all at once? Many BeyondCorp and zero-trust style products work that way. Or can it be deployed incrementally, starting with a small proof of concept?
> Tailscale is uniquely suited to incremental deployments. Since you don’t need to install any hardware or any servers at all, you can get started in two minutes: just install the Tailscale node software onto two devices (Linux, Windows, macOS, iOS), login to both devices with the same user account or auth domain, and that’s it! They’re securely connected, no matter how the devices move around. Tailscale runs on top of your existing network, so you can safely deploy it without disrupting your existing infrastructure and security settings.
Building a more accurate time service at Facebook scale
> As Facebook’s infrastructure has grown, time precision in our systems has become more and more important. We need to know the accurate time difference between two random servers in a data center so that datastore writes don’t mix up the order of transactions. We need to sync all the servers across many data centers with sub-millisecond precision. For that we tested chrony, a modern NTP server implementation with interesting features. During testing, we found that chrony is significantly more accurate and scalable than the previously used service, ntpd, which made it an easy decision for us to replace ntpd in our infrastructure. Chrony also forms the foundation of our Facebook public NTP service, available from time.facebook.com. In this post, we will share our work to improve accuracy from 10 milliseconds to 100 microseconds and how we verified these results in our timing laboratory.
TRRespass: Exploiting the Many Sides of Target Row Refresh
> Well, after two years of rigorous research, looking inside what is implemented inside CPUs and DDR4 chips using novel reverse engineering techniques, we can tell you that we do not live in a Rowhammer-free world. And we will not for the better part of this decade. Turns out while the old hammering techniques no longer work, once we understand the exact nature of these mitigations inside modern DDR4 chips, using new hammering patterns it is trivial to again trigger plenty of new bit flips. Yet again, these results show the perils of lack of transparency and security-by-obscurity. This is especially problematic since unlike software vulnerabilities, we cannot fix these hardware bit flips post-production.
A Quick Tour of the HP-9000 712/100 NEXTSTEP Workstation
> While my first NEXTSTEP system was a high-end 486 66MHz PC that I purchased from a NEXTSTEP for Intel fabricator called eCesys out of Alaska, I currently own two qualifying systems: a NeXTstation Turbo Color setup and an HP-9000 712/100 PA-RISC system. I went with the rather more unique (and powerful!) HP “Gecko” for this competition, and decided to put together a little video tour of the system.
Recent and future pattern matching improvements
> Much of writing software revolves around checking if some data has some shape (“pattern“), extracting information from it, and then reacting if there was a match. To facilitate this, many modern languages, Rust included, support what is known as “pattern matching”.
Take A Way: Exploring the Security Implications of AMD’s Cache Way Predictors
> In this paper, we are the first to exploit the cache way predictor. We reverse-engineered AMD’s L1D cache way predictor in microarchitectures from 2011 to 2019, resulting in two new attack techniques. With Collide+Probe, an attacker can monitor a victim’s memory accesses without knowledge of physical addresses or shared memory when time-sharing a logical core. With Load+ Reload, we exploit the way predictor to obtain highly-accurate memory-access traces of victims on the same physical core. While Load+Reload relies on shared memory, it does not invalidate the cache line, allowing stealthier attacks that do not induce any last-level-cache evictions.
Rust Ownership Rules
> In this post, I took the opportunity to re-summarise what I consider to be the essence of this ownership rules in Rust.
KASLR: Break It, Fix It, Repeat
Patching nVidia GPU driver for hot-unplug on Linux
> Anyway, I was kind of annoyed of rebooting every time it happens, so I decided to reboot a few more dozen times instead while patching the driver. This has indeed worked, and left me with something similar to a functional hot-unplug, mildly crippled by the fact that nvidia-modeset is a completely opaque blob that keeps some internal state and tries to act on it, getting stuck when it tries to do something to the now-missing eGPU.
The Soundness Pledge
> This post is an opportunity to share some thoughts I’ve had about soundness, Rust, and open source community.
> I believe one of the most important contributions of Rust is the cultural ideal of perfect soundness: that code using a sound library, no matter how devious, is unable to trigger undefined behavior (which is often thought of in terms of crashes but can be far more insidious). Any deviation from this is a bug. The Rust language itself clearly subscribes to this ideal, even as it sometimes falls short of attaining it (at this writing, there are 44 I-unsound bugs, the oldest of which is more than 6 years old).
Work Is Work
> Every time I’ve written or spoken about organizational design, I’ve regretted it. There’s something about staking out a position on it which manages to prove me wrong a few years later. But I’ve been having some long thinks about it again, and here’s what I’ve got. Strap the fuck in.
Mercurial's Journey to and Reflections on Python 3
> Speaking as a maintainer of Mercurial and an avid user of Python, I feel like the experience of making Mercurial work with Python 3 is worth sharing because there are a number of lessons to be learned.
> This post is logically divided into two sections: a mostly factual recount of Mercurial’s Python 3 porting effort and a more opinionated commentary of the transition to Python 3 and the Python language ecosystem as a whole. Those who don’t care about the mechanics of porting a large Python project to Python 3 may want to skip the next section or two
The BLAKE3 cryptographic hash function
> BLAKE3 is based on an optimized instance of the established hash function BLAKE2, and on the original Bao tree mode. The BLAKE3 specifications and design rationale are available in the BLAKE3 paper. The current version of Bao implements verified streaming with BLAKE3.
Translating Quake 3 into Rust
> The Rust-loving team at Immunant has been hard at work on C2Rust, a migration framework that takes the drudgery out of migrating to Rust. Our goal is to make safety improvements to the translated Rust automatically where we can, and help the programmer do the same where we cannot. First, however, we have to build a rock-solid translator that gets people up and running in Rust. Testing on small CLI programs gets old eventually, so we decided to try translating Quake 3 into Rust. After a couple of days, we were likely the first people to ever play Quake3 in Rust!
SHA-1 is a Shambles
> We have computed the very first chosen-prefix collision for SHA-1. In a nutshell, this means a complete and practical break of the SHA-1 hash function, with dangerous practical implications if you are still using this hash function. To put it in another way: all attacks that are practical on MD5 are now also practical on SHA-1.
A brief history of liquid computers
> A substrate does not have to be solid to compute. It is possible to make a computer purely from a liquid. I demonstrate this using a variety of experimental prototypes where a liquid carries signals, actuates mechanical computing devices and hosts chemical reactions. We show hydraulic mathematical machines that compute functions based on mass transfer analogies. I discuss several prototypes of computing devices that employ fluid flows and jets. They are fluid mappers, where the fluid flow explores a geometrically constrained space to find an optimal way around, e.g. the shortest path in a maze, and fluid logic devices where fluid jet streams interact at the junctions of inlets and results of the computation are represented by fluid jets at selected outlets. Fluid mappers and fluidic logic devices compute continuously valued functions albeit discretized. There is also an opportunity to do discrete operation directly by representing information by droplets and liquid marbles (droplets coated by hydrophobic powder). There, computation is implemented at the sites, in time and space, where droplets collide one with another. The liquid computers mentioned above use liquid as signal carrier or actuator: the exact nature of the liquid is not that important. What is inside the liquid becomes crucial when reaction–diffusion liquid-phase computing devices come into play: there, the liquid hosts families of chemical species that interact with each other in a massive-parallel fashion. I shall illustrate a range of computational tasks, including computational geometry, implementable by excitation wave fronts in nonlinear active chemical medium. The overview will enable scientists and engineers to understand how vast is the variety of liquid computers and will inspire them to design their own experimental laboratory prototypes.
Too Much Crypto
> We show that many symmetric cryptography primitives would not be less safe with significantly fewer rounds. To support this claim, we review the cryptanalysis progress in the last 20 years, examine the reasons behind the current number of rounds, and analyze the risk of doing fewer rounds. Advocating a rational and scientific approach to round numbers selection, we propose revised number of rounds for AES, BLAKE2, ChaCha, and SHA-3, which offer more consistent security margins across primitives and make them much faster, without increasing the security risk.
A few comments on ‘age’
> Age is a new tool for encrypting files, intended to be a more modern successor to PGP/GPG for file encryption. This is a welcome development, as PGP has definitely been showing its age recently. On the face of it, age looks like a good replacement using modern algorithms. But I have a few concerns about its design.
age is a simple, modern and secure file encryption tool.
> A simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability.
I think it’s ready now?