Posted by avsm
Sun, 08 Aug 2004 23:02:08 GMT
Thierry Deval has recently committed an impressive implementation of
malloc that uses mmap
instead of the older sbrk to allocate memory in OpenBSD.
The advantage of the new approach is that it allows all the neat randomization
features that have been added to OpenBSD recently to happen transparently in malloc
(so that you don't just get consecutive pages back as in most operating systems).
The downside is a slight slowdown, but in this age of insane CPUs, who cares?
It has had the side-effect of exposing a number of latent bugs in programs which
silently access memory locations larger than the area they malloced; I
fixed one
which had remained lurking in my gcc bounds checker (see gcc-local) for over a year, and
other bugs have cropped up in programs as important as newfs. Until someone
goes through the pain of porting the awesome Valgrind to
OpenBSD, being able to expose more bugs this way is pretty useful.
Posted in hacking, openbsd | no comments
Posted by avsm
Thu, 05 Aug 2004 11:30:00 GMT
I really love using MacOS X as a desktop machine; I've used
it since the early days on my G4 Powerbooks and it's nice to see it coming along in leaps and bounds.
Unfortunately, every time I try to hack apps on it, it seems like a big icky mess. I've mainly done QuickTime hacking, and the APIs seem to date back literally decades, with the main documentation consisting of irritatingly out-of-date sample code on the Apple website, of which some only compiles on MacOS 9.
A good point in case is their API to grab images from Firewire cameras, such as my iSight (for doing SpotCode detection). Flicking through Apple docs, one finds the Sequence Grabber API, but profiling on that turns out to do a large amount of data copying that makes meaningful real-time image detection really hard. Instead, the answers from the very helpful chaps at the QuickTime-API mailing list suggest accessing the video digitizer codec directly, and then mapping using custom OpenGL extensions to avoid copying to texture memory.
It's a neat solution, but impossible to see from the Apple documentation; luckily Daniel Heckenberg wrote the seeSaw example which does illustrate some of these concepts nicely, along with an informative paper on the subject. It's not all bad news on the MacOS X front of course - their UNIX support is really good, and looks set to continue to improve with Tiger! All I really need is a Cocoa/OCaml bridge to silence my complaints ...
Posted in hacking | no comments
Posted by avsm
Sat, 31 Jul 2004 20:59:50 GMT
I finally put up a page for Blueproxy, a handy Bluetooth RFCOMM to TCP proxy server I've been using in most of the Bluetooth hacking I've been doing for my research recently.
The current pain with Bluetooth hacking is the splintered API situation. Linux has one stack, Bluez, which it integrated into 2.4, but it's incredibly badly documented (as far as I can tell, pretty much not at all). FreeBSD has the best stack I've seen yet, based on Netgraph. MacOS X has a half-baked effort, involving setting up stuff using a GUI; however it looks like Tiger will improve this. And of course the wait continues for the Bluetooth stack in Windows XP Service Pack 2 (I refuse to risk installing it at least until it's officially released!).
The FreeBSD stack is the clear winner out of all these, with decent documentation, fewer bugs, and the most familiar interface (for example, an /etc/bluetooth/hosts file). I'm quite keen to port it to OpenBSD when I get a chance, but it does first require removing the Netgraph portions. It also looks like NetBSD has the beginnings of some code to handle the Bluetooth HCI layer; wonder how that will pan out.
Posted in hacking | no comments
Posted by avsm
Thu, 29 Jul 2004 08:53:48 GMT
The amount of spam sent to Recoil accounts has dramatically sprung
up over the last few years, sending the machine loads skyrocketing
accordingly. Luckily, we're running
OpenBSD, which added a fun
tool called
spamd(8)
a couple of releases ago.
It's activated by tracking IP addresses of known
spammers from blacklists like Spamhaus,
and redirecting them to the spam daemon via pf rules. Once the mail reaches spamd, it "tarpits"
it by dropping its TCP send and receive buffers to a very small value,
encouraging the spammers and virii to (slowly) send their malware on. If they
ever do reach the end of their data, it then rejects it with a temporary
failure - costing the spammers more resourcs if they decide to retransmit it.
The load has dropped quite a bit since I activated this filtering; it seems
to help against some of the latest worms quite a lot, which just
connect to port 25, spew off a buffer-overflow attempt, and repeat this
once every few seconds. Since spamd, things take a bit longer though!
quick spamd: 221.2.232.138: connected (9/9), lists: spamhaus
quick spamd: 221.2.232.138: disconnected after 431 seconds. lists: spamhaus
Very satisfying. I did play with the greylisting mode of spamd as well, but it wasn't quite as successful as some valid mail sites such as EDAS (bless its underwhelming soul) take five days to send conference paper rejections into a greylisted system. Public whitelists do exist, but I think I'll wait a while and see if things mature a little more first.
Posted in hacking, net | no comments
Posted by avsm
Sun, 25 Jul 2004 22:46:49 GMT
I used to do an awful lot of PHP hacking, but over the last few years, the boring gods of security and correctness have snared me, leaving me frustrated with the effort and resources required to create and maintain dynamic web content.
So I've converted my site over to static HTML, and started switching our main web-servers to use thttpd instead of Apache. The performance difference has been absolutely staggering, as the humble hardware behind fork.recoil.org managed to survive a slashdotting and mentions on opengl.org (for the latest release of OpenFX) without breaking a sweat.
thttpd is great; it uses the BSD kqueue(3) kernel event mechanism, and is single-threaded (removing the endearing fork-bomb effect Apache has when hit by a burst of traffic). There are quite a few good programs to help generate static content as well; my new blogging tool of choice is blosxom, which fits into the UNIX way of doing things absolutely perfectly.
Posted in hacking, recoil | no comments
Posted by avsm
Mon, 28 Jul 2003 13:29:00 GMT
Spent a few hours this weekend implementing privilege separation for syslogd in OpenBSD; I was curious to see how hard it would be to reason about the flow of execution of a fairly simple C daemon. I'm thoroughly sick of C now; my next task is to write an SSH2 server in Objective Caml to see how much better (or worse) it is than the equivalent C code in OpenSSH.
Posted in hacking | no comments
Posted by avsm
Thu, 10 Jul 2003 23:17:00 GMT
Had a great time in Las Vegas at SAM 03. The conference wasn't up to much apart from a few interesting papers in our session (one on behaviour-based authentication from some guys at Reading was funny and innovative). We did however hire a car and have a really fun day wandering around the desert checking out the natives.
Back in Princeton, the work's pretty hectic. Been stuck deep in the innards of the FreeBSD kernel for the last few days, ripping out bits of code to test out our cunning new networking idea. We got it to work (late) last night, so now it's the spit and polish phase; the most painful ...
On the OpenBSD front, I finally committed the gcc static bounds checker patch I've been playing with for a few months. It found hundreds of really obviously bad bounds to functions such as strlcpy(3) and sscanf(3) in the source and ports trees. The local compiler gurus (Scotty and Sharpy) have suggested various ways to improve it such as interval analysis, so I might hack on that if a burst of free time holds me to ransom any time soon.
PS: T3 was fun!
Posted in travel, hacking, openbsd, usa | no comments
Posted by avsm
Mon, 25 Nov 2002 15:20:00 GMT
Yawn; just hacking NetBSD into booting under the XenoServer. The XenoServer reserves the top 512M of memory for its own nefarious purposes, so it requires setting the appropriate segment registers and tweaking a few defines.
If I can get away from here in time, I'll go visit Claire in hospital with Jon and David with a bunch of flowers or chocolates; sounds like she needs cheering up!
And someone convince David that benchpressing at 11pm is a bad idea please... possibly the worst bench session ever (except possibly that time I dropped it when Salman was 'spotting' me).
Posted in cambridge, hacking | no comments
| 