rust

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:

A half-hour to learn Rust

Jan 27, 2020

27 min #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

Loading multiple ELF objects

Jan 26, 2020

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

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.

The simplest shared library

Jan 22, 2020

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

In our last article, we managed to load and execute a PIE (position-independent executable) compiled from the following code:

; in `samples/hello-pie.asm`

        global _start

        section .text

_start: mov rdi, 1      ; stdout fd
        lea rsi, [rel msg]
        mov rdx, 9      ; 8 chars + newline
        mov rax, 1      ; write syscall
        syscall

        xor rdi, rdi    ; return code 0
        mov rax, 60     ; exit syscall
        syscall

        section .data

msg:    db "hi there", 10

ELF relocations

Jan 19, 2020

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

The last article, Position-independent code, was a mess. But who could blame us? We looked at the world, and found it to be a chaotic and seemingly nonsensical place. So, in order to blend in, we had to let go of a little bit of sanity.

The time has come to reclaim it.

Short of faulty memory sticks, memory locations don’t magically turn from 0x0 into valid addresses. Someone is doing the turning, and we’re going to find out who, if it takes the rest of the series.

Position-independent code

Jan 13, 2020

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

In the last article, we found where code was hiding in our samples/hello executable, by disassembling the whole file and then looking for syscalls.

Later on, we learned how to inspect which memory ranges are mapped for a given PID (process identifier). We saw that memory areas weren’t all equal: they can be readable, writable, and/or executable.