rust

A new website for 2020

Jun 26, 2020

42 min #announcement · #rust · #ftl-infra

Hi everyone. Has it been two months since I last posted something? Yes it has!

That seems like a nice round duration, so let’s break the silence with a few announcements.

I have a new website

If everything goes well, you’re on it right now.

Does it feel okay? Take a minute to accustom yourself to your new surroundings. Identify potential sources of fresh water. Gather some supplies with which to fashion a makeshift shelter.

Thread-local storage

Apr 26, 2020

42 min #os · #assembly · #linux · #rust · #no_std

Welcome back and thanks for joining us for the reads notes… the thirteenth installment of our series on ELF files, what they are, what they can do, what does the dynamic linker do to them, and how can we do it ourselves.

I’ve been pretty successfully avoiding talking about TLS so far (no, not that one) but I guess we’ve reached a point where it cannot be delayed any further, so.

A no_std Rust binary

Apr 13, 2020

27 min #os · #assembly · #linux · #rust · #no_std

In Part 11, we spent some time clarifying mechanisms we had previously glossed over: how variables and functions from other ELF objects were accessed at runtime.

We saw that doing so “proper” required the cooperation of the compiler, the assembler, the linker, and the dynamic loader. We also learned that the mechanism for functions was actually quite complicated! And sorta clever!

More ELF relocations

Apr 06, 2020

28 min #os · #assembly · #linux · #rust

In our last installment of “Making our own executable packer”, we did some code cleanups. We got rid of a bunch of unsafe code, and found a way to represent memory-mapped data structures safely.

But that article was merely a break in our otherwise colorful saga of “trying to get as many executables to run with our own dynamic loader”. The last thing we got running was the ifunc-nolibc program.

Safer memory-mapped structures

Mar 03, 2020

18 min #rust

Welcome back to the “Making our own executable packer” series, where digressions are our bread and butter.

Last time, we implemented indirect functions in a no-libc C program. Of course, we got lost on the way and accidentally implemented a couple of useful elk-powered GDB functions - with only the minimal required amount of Python code.

The article got pretty long, and we could use a nice distraction. And I have just the thing! A little while ago, a member of the Rust compiler team stumbled upon this series and gave me some feedback.

GDB scripting and Indirect functions

Feb 27, 2020

41 min #rust · #gdb · #nom

In the last article, we cleaned up our dynamic linker a little. We even implemented the Dynamic relocation.

But it’s still pretty far away from running real-world applications.

Let’s try running a simple C application with it:



// in `samples/puts.c`

#include <stdio.h>

int main() {
    puts("Hello from C");
    return 0;
}



$ cd samples/
$ gcc puts.c -o puts
$ ../target/debug/elk ./puts
Loading "/home/amos/ftl/elk/samples/puts"
Loading "/usr/lib/libc-2.32.so"
Fatal error: Could not read symbols from ELF object: Parsing error: String("Unknown SymType 10 (0xa)"):
input: 1a 00 10 00 a0 bf 0b 00 00 00 00 00 c1 00 00 00 00 00 00 00

Working with strings in Rust

Feb 19, 2020

45 min #rust

There’s a question that always comes up when people pick up the Rust programming language: why are there two string types? Why is there String, and &str?

My Declarative Memory Management article answers the question partially, but there is a lot more to say about it, so let’s run a few experiments and see if we can conjure up a thorough defense of Rust’s approach over, say, C’s.

Dynamic symbol resolution

Feb 02, 2020

26 min #os · #assembly · #linux · #rust · #linkers

Let’s pick up where we left off: we had just taught elk to load not only an executable, but also its dependencies, and then their dependencies as well.

We discovered that ld-linux walked the dependency graph breadth-first, and so we did that too. Of course, it’s a little bit overkill since we only have one dependency, but, nevertheless, elk happily loads our executable and its one dependency: