On OpenBSD, there is a rule that you link with libc to interface with the kernel, because that’s where the syscall stubs live. This causes a great deal of consternation for partisans of other languages, because they don’t want to link “all of libc”. But when does anything link all of libc?

more...

We have a new edition of POSIX, which means new rules, new regulations, new red tape. But not new lines. Which is to say, posix at long last banishes new lines in file names.

more...

Sometimes pipes get stuck. To recap, if we run this command...

~/src/usr.bin/grep> tail -200 util.c | grep unsigned | grep int
grep_revstr(unsigned char *str, int len)

... we get the expected output. If we run it this way, however, there’s no output.

~/src/usr.bin/grep> tail -f -200 util.c | grep unsigned | grep int

The file isn’t being appended, meaning tail won’t exit, so we don’t expect the pipeline to ever finish, but we would like to see the current results.

Fortunately, grep provides an lbflag we can set. In this case, if the input is a pipe, we’ll assume there’s something fancy going on, and switch to line buffering.

        struct stat sb;
        fstat(0, &sb);
        if ((sb.st_mode & S_IFMT) == S_IFIFO)
                lbflag = 1;

Easy fix. (Or one can read the manual.)

But this is excessive. What about those times when we want the efficiency of buffering? There are lots of possible pipelines that don’t involve tail. What we can do instead is take a peek at some of our neighbors and see what’s really going on. Not perfectly accurate, but probably good enough.

static void
checklbflag()
{
        pid_t pgrp = getpgrp();
        struct kinfo_proc ki[24];
        size_t len = sizeof(ki);
        int mib[6] = { CTL_KERN, KERN_PROC, KERN_PROC_PGRP, pgrp,
                sizeof(ki[0]), sizeof(ki)/sizeof(ki[0]) };

        sysctl(mib, 6, ki, &len, NULL, 0);
        for (size_t i = 0; i < len / sizeof(ki[0]); i++)
                if (strcmp(ki[i].p_comm, "tail") == 0)
                        lbflag = 1;
}

Alas, this requires including <sys/sysctl.h> which will slow down our compiles.

It is also possible, using forbidden magic, to determine whether the pipe we are reading from is being written to by tail, as opposed to a tail at the end of the pipeline, but that’s left as an exercise for the reader.

I like using pledge and unveil in my web apps. Especially unveil offers a nice degree of protection against common web app problems, like the dreaded double dot traversal. For go, I use a simple wrapper which gets pasted into each project.

more...

OpenBSD has provided binary patches for a select few architectures for a while now, to save users from the daunting task of running make on their own. Alas, this means you might now apply a patch without first reviewing it. In the olden times, you had a source patch, so obviously you meticulously studied every line before application, just like you advised new users on IRC to do. But now, who will believe you do this when the binary syspatch is right there, so easy, so tempting.

more...

This is approximately as wise as taking off from Mars in a ragtop rocket, but don’t worry, the math all checks out.

more...

My SSD is probably pretty fast, but maybe a faster one would let me compile a kernel even quicker by reducing the time spent waiting for I/O to complete. First though, I need to determine its latency, and the benchmark tool available to me, dd, measures throughput not latency. We need to go deeper.

more...

It started with a simple feature addition. It always does. And then the murders began. I don’t think I’ve ever introduced so many bugs by changing so few bits.

more...

Some bugs, some ambiguities, some assumptions, some bad results. Nothing went too seriously wrong, but it seems like an interesting case study in code evolution. I had nothing to do with finding or resolving the issues, I’m just commenting.

more...

OpenBSD aims to be a secure operating system. In the past few months there were quite a few security errata, however. That’s not too unusual, but some of the recent ones were a bit special. One might even say bad. The OpenBSD approach to security has a few aspects, two of which might be avoiding errors and minimizing the risk of mistakes. Other people have other ideas about how to build secure systems. I think it’s worth examining whether the OpenBSD approach works, or if this is evidence that it’s doomed to failure.

more...