Articles tagged #rust

Thumbnail for {{ page.title }}

A no_std Rust binary

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!

Thumbnail for {{ page.title }}

More ELF relocations

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.

Thumbnail for {{ page.title }}

Safer memory-mapped structures

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.

Thumbnail for {{ page.title }}

GDB scripting and Indirect functions

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

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.

Thumbnail for {{ page.title }}

Dynamic symbol resolution

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:

A half-hour to learn Rust

In order to increase fluency in a programming language, one has to read a lot of it.

But how can you read a lot of it if you don’t know what it means?

In this article, instead of focusing on one or two concepts, I’ll try to go through as many Rust snippets as I can, and explain what the keywords and symbols they contain mean.

Ready? Go!

Variable bindings

Thumbnail for {{ page.title }}

Loading multiple ELF objects

Up until now, we’ve been loading a single ELF file, and there wasn’t much structure to how we did it: everyhing just kinda happened in main, in no particular order.

But now that shared libraries are in the picture, we have to load multiple ELF files, with search paths, and keep them around so we can resolve symbols, and apply relocations across different objects.

Go back to the homepage.