It’s been a little while, so a few more notes about ActivityPub implementation, federation, and other odds and ends. There’s no real order to these notes, just things that have come up in the past two months.

more...

I’ve had an iPhone for many years, and an iPad for not quite as long. People would tell me I should switch to Android. I thought they were crazy. I recently got some Android devices. Now I know they are crazy. Some notes on recent experiences with a Moto G6 and Samsung Tab S5e.

more...

The wifi network at BSDcan, really the UOttawa network, blocks a bunch of ports. This makes it difficult to connect to outside machines using “exotic” protocols, basically anything except http or https. There are many ways to resolve this, here’s what I did.

more...

Common problem for operating system fuzzers is breaking the system they’re running on. Some forms of damage are expected, some are not, and sometimes it’s difficult to tell which is which.

A few days ago, a stack leak bug was fixed in FreeBSD. A similar fix for OpenBSD was committed. And then syzkaller came kalling just a few days later.

panic: bad dir

There’s a few possible causes for this, but inspection revealed that the most likely case might be a directory entry missing the nul terminator. The timing certainly seemed suspicious. Could there be an off by one?

memset(newdirp->d_name + (cnp->cn_namelen & ~(DIR_ROUNDUP-1)), 0, DIR_ROUNDUP);

Actually no. syzkaller had found a way to create filesystem corruption through one of the “expected” damage paths, but the test case was a little obfuscated. More study revealed it was calling mknod to create a new device that happened to be equal to /dev/sd0c and opening it, and then calling pwrite to write some garbage to a random spot.

mknod("banana", 0777, 0x0402);
open("banana")
pwrite(3, "oops", 4, 0x9000);

Not recommended.

Further complicating the matter was that syzkaller didn’t know that pwrite is one of the magic syscalls that takes a padding argument before off_t. This didn’t affect the test, per se, but makes it harder to interpret because syzkaller calls things directly. (The actual syscall in use was the iovec variant, pwritev.)

syscall(SYS_pwritev, r[0], 0x200002c0, 1, 0);

If you read the man page for pwritev that looks correct. But inspecting src/sys/kern/syscalls.master reveals that the fourth argument is actually a pad argument, and the offset is the fifth argument. So the call above was writing to an offset that was not zero.

Not the first fuzzer to encounter this oddity. More details here.

In the end, it was just coincidence that syzkaller found a new way to corrupt its filesystem a few days after a filesystem commit.

Something that’s annoyed me for some years is that all the web sites I build don’t work quite right with my iphone. Scroll down a page, visit a link, go back, and safari jumps back to the top of the page. Very annoying. Pretty much no other site I visit seems to have this problem, yet I couldn’t figure out what I was doing wrong since I’m barely doing anything at all. There are some support forum complaints about similar bugs, but mostly from several years ago, and mostly “solved: it works now” without explanation.

Finally, figured out what seems to be the problem. The iphone introduces its own viewport meta tag, to define the screen dimensions, and control whether the user can zoom or not. A lot of sites abuse this to the point of unusability, so I very determinedly stayed clear. But without a viewport tag, safari is really dumb.

Without a viewport setting safari picks some defaults and renders the page to fit. They seem fine to me. The problem is that after leaving a page and coming back, safari has forgotten what size it picked, picks again, and then has to reflow all the page content. Even though it has picked exactly the same dimensions as the previous render. With the result that it forgets its scroll position and resets to the top of the page. Sigh. At least that’s what I’ve determined is going on.

So I finally broke down and added a viewport tag to the header. This required futzing with the CSS some more because now it rendered to a much smaller virtual canvas, but generally solvable.

Anyway, this frustrated me for a long time, I couldn’t find any useful information about it, and now it seems to work.

I posted a tiny png, a mastodon stepped on it, and... it got really big.

more...

I had an array with some duplicates. I wanted to remove them. I know how to do this, but I searched for solutions anyway to make sure I wasn’t missing some trick. The results were disappointing, very language specific, and rarely discussed run time. And if we’re working with an unsorted array, the provided answers are even worse. Just sort the array first. Well, duh; any problem with unsorted data can be transformed into a problem with sorted data by sorting first. That’s not very interesting, though, and maybe there’s a reason the data is unsorted. Here’s a few solutions I worked through, but no stunning algorithmic breakthroughs.

more...

honk is my take on a federated status updater. One might say it’s opinionated software. Since my opinions are correct, this makes honk the world’s first provably correct social media application. Here’s a formerly brief rundown of things that work, things that don’t work, and things that won’t work. Plus some complaints about how other people do things. The version number, 0.1, indicates your expected level of satisfaction.

more...

This is a little tour of some software I took today. One of the topics that consistently comes up when people discuss what operating system to run on their laptop is how much battery life to expect, and the answers are all over the map. The focus always seems to be on the kernel and how advanced its scheduler algorithm is, and the minutia of interrupt controllers. We throw around terms like race to sleep. But rarely do I see anyone mention the impact that the software they choose to run spending millions of CPU cycles on trivial tasks might have on battery life. Especially ironic if that software ends up being the software we’re running to monitor how much battery is left.

more...

I’ve been reading a lot about the benefits of virtualization and cloud deployment. And how to integrate these systems with modern web client design. It was all very exciting. So now I’m pleased to announce flak is fully cloud enabled. Here’s the story of my incredible journey.

more...