Async fn in trait… not

I was planning on showing the in-progress async_fn_in_trait feature in the context of my website, but it turns out, I can’t!

My website uses two databases: one local SQLite database for content, and a shared Postgres database for user credentials, preferences etc. Migrations are run on startup, and each migration implements one of the following traits:

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.

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.

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.

In part 1, we’ve looked at three executables:

• sample, an assembly program that prints “hi there” using the write system call.
• entry_point, a C program that prints the address of main using printf
• The /bin/true executable, probably also a C program (because it’s part of GNU coreutils), and which just exits with code 0.

We noticed that when running entry_point through GDB, it always printed the same address. But when we ran it directly, it printed a different address on every run.

So! Rust futures! Easy peasy lemon squeezy. Until it’s not. So let’s do the easy thing, and then instead of waiting for the hard thing to sneak up on us, we’ll go for it intentionally.

Cool Bear's hot tip

That’s all-around solid life advice.

Choo choo here comes the easy part 🚂💨

We make a new project:

$ cargo new waytoodeep Created binary (application) `waytoodeep` package

I’ve recently come back to an older project of mine (that powers this website), and as I did some maintenance work: upgrade to newer crates, upgrade to a newer rustc, I noticed that my build was taking too damn long!

For me, this is a big issue. Because I juggle a lot of things at any given time, and I have less and less time to just hyperfocus on an issue, I try to make my setup as productive as possible.

Disclaimer:

Trigger warning: depression, talk of suicide.

It’s been a while since I wrote a mental health piece — but I think it’s important to occasionally stop, take a breather, and think about how we feel.

So.

deep breath

I’m okay, I think? Just a little restless.

A bit of personal context

For those keeping score, I went through major life events in 2023 — a divorce, a move, and the news that I might need a second round of jaw surgery.

In the wake of Why is my Rust build so slow?, developers from the mold and lld linkers reached out, wondering why using their linker didn’t make a big difference.

Of course the answer was “there’s just not that much linking to do”, and so any difference between mold and lld was within a second. GNU ld was lagging way behind, at four seconds or so.

It happened when I least expected it.

Someone, somewhere (above me, presumably) made a decision. “From now on”, they declared, “all our new stuff must be written in Rust”.

I’m not sure where they got that idea from. Maybe they’ve been reading propaganda. Maybe they fell prey to some confident asshole, and convinced themselves that Rust was the answer to their problems.