failure is not an option

There’s a great writeup over on Matasano (home of many a great writeup) about how a supergenius hacker was able to exploit a NULL pointer coming out of malloc failure to run arbitrary code in Flash. This is interesting to Mozilla in part because a lot of our users have Flash installed, but also specially interesting to me because we’re working with Adobe to converge on a common, high-performance scripting engine for both JavaScript-as-she-is-written-today and ECMAScript future. I’m actually in Boston tomorrow to work with some Mozillians to map out the next interim milestone on our way to JS2 and Tamarin.

As part of the same general effort, known as “Mozilla 2″, we’re also going to be changing how we do memory allocation, so that — just as Thomas recommendsout of memory is a hard-stop failure, rather than an opportunity for a clever (or, as in this case, hyper-clever) exploit to take hold.

Of course, in a system as large as ours, you don’t want to do it all by hand, so we’ll be using static analysis tools to identify and rewrite our code mechanically. This will give us better performance from less computer time spent checking allocation results, reduced code complexity from less human time spent reading through tedious failure-handling code, and protection against a large class of potential attacks. That’s a pretty nice set of things to get in one package.

that’s when I shoot the water cannon

Taras-and-company’s ridiculous progress continues apace, in pursuit of tools to let us master — rather than be mastered by — the scale and…uniqueness of our codebase. One great milestone is the addition of build-time static checking to the mozilla2 build process. If the enforcement opportunities presented by static-checking.js are insufficient, then this guy in Atlanta may have something to help us.

robot vigilante

Prototyping

I’ve been taking notes at some of the GDC lectures, and when I get a chance I’ll be turning them into posts of some sort (writing things of that scale on the blackberry and without a preview cycle is not a thrilling prospect).

So far I’ve been to, among other fun stuff, three presentations on prototyping and experimentation: a great talk by the Kyles from the Experimental Gameplay Project, an excellent exposition by Chris Hecker and Chaim Gingold from the Spore team, and a decent post-mortemish thing about the Civ4 iterative development process.

It’s been pretty timely for me, as I’ve been thinking a lot lately about how to make Firefox and our platform more amenable to quick experimentation — both for things like extensions and web applications. Much more about that later, but it’s been very energizing and I think GDC will make a substantial, if indirect, contribution to my work this coming year. [tags]gdc, mozilla, software development[/tags]