Speaking of unearthing bugs, I'm surprised I've not found any mention of anyone fuzz testing NetBSD syscalls. There's a crashme tool which, despite the one-line summary doesn't actually call syscalls explicitly (although it may stumble across them at random) - it just executes arbitrary sequences of random numbers as code, in order to make sure all the CPU trap handlers work correctly...
So I may throw together a tool to do that for syscalls. Needless to say, it ought to be run as an isolated user (so it can only trash its own files), maybe in a chroot, and ideally on a machine without network access (for it could, in theory, open a network socket and do something unneighbourly :-).
This would be a good test of the higher-level inter-process isolation facilities in the OS kernel - namely, it'd help to find security holes such as local denial of service attacks against the kernel!
Also, another fun idea might be a fuzz tester for Xen hypercalls...
pkgsrc, the software package installation system that comes with NetBSD, is a lovely and powerful thing, but the default out-of-the-box setup is pretty basic. There's a lot you can do to bring the power of it out that's either hidden in the pkgsrc manual or in extension packages.
So here's my quick guide to getting the best out of pkgsrc.
Read more »
Recently, a feeling has started to appear in my life that's been missing for many years...
When I was a kid, I often felt geek exhilaration. All I had to do was sit with a notepad and think for a while and I'd come up with a design for something cool. Now, the kind of thing that interests me is infrastructure - I've always been more interested in designing, say, a game engine than in writing an actual game. So I'd sit down and pluck a random problem from the air and design an infrastructure for solving it. And then I'd feel excited about the lovely potential of this infrastructure.
Alas, this happened at a much higher rate than I could ever implement these things, so I had a sources directory laden with unfinished projects. But it was still fun.
Anyway, with age and responsibility and work and bills and stress this happened less and less; I still got to invent infrastructures, since it's part of my job, but I'd only get to design one every month or so at best. Five minutes of fun, then a month of implementation. And the problems I was trying to solve were relatively boring, and the solutions required often constrained to just solve the immediate needs of the users for the next year or so, rather than a sparkling generic platform upon which anything could be built for ever more.
But recently, for some reason, it's started returning.
Read more »
I've just finished upgrading the database services on love, my hosting server cluster... Phew. I started at 11pm, and it's now 2:30am. Much time spend shepharding the upgrade process. But we now have nice recent mysql and postgresql installations!
Well, at long last, I'm finally getting paid to mess around with the kinds of things I find REALLY interesting - a task which, at the moment, involves setting up shared memory and semaphores between processes for some high-speed shared cache action. Sort of like PostgreSQL does.
Anyway, I've found a few quirks of Mac OS X's System V IPC setup that I thought I'd best share.
ipcs should be setuid or setgid or something. It grovels in kernel memory to find out what IPC objects exist and their state, but when run as a normal user, it doesn't have permissions to do so and fails silently; ipcs always returns that nothing's allocated, while ipcs -T reports garbage values.
Talking of ipcs -T, the IPC system limits are (as usual) set via sysctls. But if you try and change them, they refuse to alter. It turns out that you can set them, but only once - the first time this set of sysctls is written to the kernel, it sets up its internal data structures and considers the sysctls read-only thereafter until the next boot.
You have been warned.
I'm reporting the former at least to Apple as a bug...
Computing | alaric | 
Mon 5th Mar 2007 3:59 pm | 
Comments (0) 
Subscribe