The example most programmers will understand today is with a yacc-like tool (or lex, for that matter):

y.tab.c y.tab.h : whatever.yacc

       $(YACC) $(YFLAGS) $<

If you’ve ever used yacc, or the GNU equivalent, bison, or any other code generator, you’ll understand the pattern. There’s a set of input files, usually either just one, or one plus some other files generated by a lexer generator. And the input files are read by the code generator tool, and the code generator tool produces a bunch of different output files all at the same time.

The syntax that this ‘make’ tool I was reading about used to indicate this was a plus sign:

y.tab.c + y.tab.h : whatever.yacc

And that plus sign was enough to let the ‘make’ tool know what was going on with the simultaneous generation of both files.

The company in question was not a client. It was my second serious job after college. I started working there in the (late) 1980’s. And the ‘make’ tool in question was make, as provided with SunOS 3 and 4. (Not Solaris. That came later.)

Yeah, so?

I told that story for a reason: to point out that this somewhat niche-market problem has been solved, in a widely-available system, using a trivial syntax enhancement. The solution has been around for more than 20 years. And GNU make still gets it wrong.

The latest GNU make version provides a feature that almost solves the same problem. Except that it doesn’t. And that “feature” is a hack.

It’s documented in the manual, but not mentioned in a header in the contents, so you have to just know, or have someone give you a link. Google won’t help you find it. (It’s here.)

And of course the syntax used for the GNU make not-quite-but-maybe-almost hack is: two targets separated by spaces.

That’s right, the GNU version looks like:

a b : input

Which you might find confusing, because the GNU make syntax for two targets that do not all get regenerated at the same time, but instead require the recipe to be executed once for each output looks like:

a b : input

See the difference? Of course not, because at this level of abstraction there is no difference. The rules look exactly the same.

If you don’t know the secret – which is that the run-once or run-multiple-times behavior depends on whether the rule is a pattern rule or not – then you’re SOL, because there’s no visible indicator.

It’s worth pointing out that there’s a method to the madness of the GNU make weenies. The justification, if I were dumb enough to ask for one, would be something like this: the only time this kind of thing ever arises (in C) is when you’re using yacc or rpcgen. (Rpcgen is the reason the Sun guys added the rule, I’m fairly sure.) And yacc/rpcgen always get used in such a way that the filenames always have a common root. So making this incredibly lame hack makes total sense, because nobody ever does this, but if they did they’d be happy it was this way.

Bah, humbug!

I don’t do a lot of C programming any more. There are other languages that are generally much more suited to what I’m trying to do. Some of those languages are “static” languages, like C++, Java, and D. And some of those languages are “dynamic” languages, like sh, perl, and scheme.

But in both camps, you’ll find languages that use directory names and file names to reflect the classes, modules, packages, units, or whatever-it’s-called defined inside them.

This is important because if I’m going to generate code, I want to be free to generate code using file and directory names that are meaningful to, and constrained in, the context of the programming language I’m actually using.

I really, really, really don’t want to have to conform to a naming convention inspired by a tool I’m not using in a language I don’t care about that is the basis for a syntax hack in make!

Ultimately, I think this is an example of a couple of things. First, that the GNU make guys are suffering a vision problem because they’re focused on building a core set of applications, using a small set of languages.

Second, I think they’re afraid to admit that other people, when faced with a similar set of problems as them, have come up with useful solutions. Back when GNU make got started, SunOS was the dominant Unix. And the guys at Sun were doing a fine job of carrying forward the tool suite. But heavens! For GNU to copy a useful feature of a popular tool would be to admit that we aren’t the sole source of clever ideas. Oh, noes!

Thus, we have the open source curse: Gnot Invented Here syndrome.

And also thus – more of a pain in my tuchus, thus – we have a version of GNU make that forces me to jump through a bunch of hoops to accomplish something that I could have done in two lines back in 1988.

Today I was chatting with some folks on IRC, and the subject of binary searching came up. Now, I don’t know if this is going to surprise you, but in the last few years there has been some “movement” in the performance arena as far as thing we just “know”. It turns out, for example, that the “qsort” function isn’t the fastest horse in the race any more. And it turns out that bsearch is getting a little long in the tooth, too.

“Mon dieu! How can this be?,” you ask. Well, it’s templates.

The C++ guys apparently listened to Philip Greenspun, and decided that the way to better performance was to build a lisp interpreter into the compiler. That lisp interpreter is called “template metaprogramming” (TMP), and the languages like C++ that support TMP can use it in some surprising ways.

The key thing to realize here is that there’s a trade-off involved. The old C standard library functions are – no question – about as fast as they can be. But the TMP guys came to the realization that the library functions were just that: functions. And so calling qsort or bsearch means passing in a callback function that takes a couple of pointers and compares whatever they point to.

This is very generic, but it comes at a fairly high cost in terms of run-time. Calling a function to make a comparison is a huge performance lose, especially on a fast CPU with a good sized cache. All that stuff you’ve heard about cache misses and branch prediction and what-not? Well, it becomes relevant if you have to call through a pointer to the compare function, and it gets doubly relevant if your compare function turns around and calls some other function – like strcmp.

So the template version of all this uses the same logic as the hoary old C standard library chestnuts, but it uses templates to dynamically build a special-purpose function for doing just exactly the Quicksort or binary search that you need to do right now.

The obvious down side? Each place where you invoke qsort or bsearch generates a different function. Big code bloat here, folks.

The up side? Breaking through the “call a function to compare two items” barrier. For small types – like int, float, etc. – and for “fully equipped” types like strings, there will be enough code laying around that the compiler can in-line some, if not most or all, of the comparison logic. Comparing strings will always require looping through arrays. But comparing two structs? That’s easy to inline. Comparing two ints? Please!

Crossing Over

So with this in mind, I set out to find the “cross over” point. Put simply, where do the performance curves of linear seach (lsearch) and binary search (bsearch) cross? That is, for N = how many items does it make more sense to use a binary search than to iterate?

Now, here’s what we know about bsearch: it has performance characteristic O( log n ). And we know that lsearch has performance characteristic O( n ). But what does that mean, exactly?

First, every routine has some overhead. When a subroutine is called, you push some information on the stack, initialize some variables, and then do your work. And later, you takes stuff off the stack, free your resources, and return. That’s overhead.

Next, in the process of doing the actual work, you have to perform interim computations. For example, linear search basically requires some mechanism for iterating through the array you are searching. And that’s going to be a pointer or an integer or something. Updating that iterator is part of the structural cost of the algorithm. A bsearch algorithm typically involves computing (low + (high-low)/2). That’s the middle point for the search, and that’s a part of the structural cost.

Those structural costs can be high, sometimes. So saying that an O( log n ) function is faster than an O( n ) function automatically implies a caveat, so long as n is big enough that the structural and overhead costs get washed out. And that’s why I was curious about the cross-over number. Because with templates, the call-a-function-through-a-pointer structural cost is gone. And so my understanding of where the lines cross is no longer valid.

Great! Another ‘D’ in programming…

The language in question isn’t C++, though. It’s D. Now, D is a lousy name for a programming language, just like C is. Because Google is not your friend if you’re searching for “D”. Nor is “file.d” going to be a win, either, because that’s the default name for dependency files in a lot of build systems. So D wasn’t the best possible choice of names, and it can be hard to find info about it. To save you some grief, have a look at http://www.digitalmars.com/d – that’s the “official” D site, if there is such a thing. (For myself, I’ve taken to using “PL/D” as an abbreviation.)

PL/D version 2.0 supports templates. So here’s bsearch, as a can-find type function:

bool bsearch( T, alias cmp = "a < b" )(T[ ] array, T key )
{
	int left = 0;
	int right = array.length;

	while( left + 1 < right ) {

		int middle = ( left + right ) / 2;
		T am = array[ middle ];

		if( binaryFun!( cmp )( key, am ) ) {

			right = middle;
		}
		else {

			left = middle;
		}
	}

	// return a[0] == key
	return ! binaryFun!( cmp )( key, array[ 0 ] )
		&& ! BinaryFun!( cmp )( array[ 0 ], key );
}

Now I know that this version doesn't do early exit. But it's a little more readable to folks who might be new to the whole template thing, especially with PL/D. One thing I like more about D than C++ is that templates are instantiated like foo!( T )( a, b ) instead of foo< T >( a, b ). If nothing else, it's more html friendly.
I won't explain all the neat-o features of the language here - see the link above for that. I will point out that this version generates a binary function using "a < b" by default, and generates a direct call to that function in the comparisons. As a result of the direct (instead of indirect - through a pointer) function calls, the compiler can inline them, resulting in the comparison being made right in the function itself.
The testbed was an array of randomly-generated integers. The driver code looked like this:

	// ========================
	Thread.sleep( 1 );
	timer.start();

	foreach (iter; 0 .. ITERATIONS )
		bsearch(a[], cast(int)(rand() % ELEMENTS));

	timer.stop();
	writefln( "Bsearch: %f usec (avg)", cast( float ) timer.microseconds / ITERATIONS );
	writefln( " .... Cycle: %f usec (avg)", ( timer.microseconds - overhead ) / ITERATIONS );

	// ========================
	Thread.sleep( 1 );
	timer.start();

	foreach (iter; 0 .. ITERATIONS ) {
		int key = rand() % ELEMENTS;
		csearch( &key, &a[ 0 ], ELEMENTS, int.sizeof, &compare_ints );
	}

	timer.stop();
	writefln( "Csearch: %f usec (avg)", cast( float ) timer.microseconds / ITERATIONS );
	writefln( " .... Cycle: %f usec (avg)", ( timer.microseconds - overhead ) / ITERATIONS );

Where most things should be obvious, but I’ll point out that the Thread.sleep calls were for 100 nanoseconds each – just enough to give control back to Windows so it hopefully wouldn’t interrupt the loops. The “csearch” call in the second block is actually a call to the bsearch function in the C standard library – I created an alias for it since I already had a bsearch function.

Overall, for ELEMENTS = 1000, the cycle time for the template based bsearch was about 0.12 usec. The cycle time for the call-a-function C library version was about 0.165 usec. So for trivial comparisons, the template-based version gives a 25+% speed benefit – that’s why I was interested in running the tests!

Obviously, this number depends on the number of comparisons. For ELEMENTS = 100, you’re looking at log n = 7 instead of 10 comparisons – csearch should catch up a little bit. For ELEMENTS = 100,000, it would be 17 instead of 10 and presumably the template version would show even better performance.

The Edge of Seventeen

But that’s not why I started this. I wanted to know how well the template bsearch code would do against lsearch – linearly scanning the array. It seemed like a safe bet that 1,000 elements would be a win for the binary search…and it was. (whew!) But would the same be true for 100 elements? 10?

Well, for me, the number is 17. If ELEMENTS = 17, then lsearching the array (using a template based lsearch) is faster than bsearching the array (using a template based bsearch). (On the other hand, template based lsearch crosses over C-style bsearch at 61 items!)

Those performance numbers depend on a lot of things. Most importantly, they depend on the relative speed of your comparison code versus the structural code of the search function.

What does that mean? Well, take a look at the a program called git-bisect. This program is a shell script that uses a binary search to find a build failure. Bisect knows the list of changes that were made to your source code, so it can pull out a version, build it, test it, and decide whether the problem is in that version or elsewhere.

The issue, though, is that the “comparison function” involves pulling out your 30 million lines of code, running a build, and then running the test that identifies whether the bug is in this version or not. The build and test process takes so much longer than the “add two numbers and divide by two” of the binary search that it’s a no brainer – you’re almost always going to use the bsearch version.

But when the compare is a single CPU instruction, it’s a different story. In that case, the overhead of the bsearch pushes the crossover point far out past where it is in theory. If your compiler is smart enough, and when you’ve got enough memory to allow it to inline these kinds of functions…well, we have to draw a line somewhere.

All in all, it’s a pretty nice keyboard, and the whole stand+keyboard thing has really worked out well for me. But I have to say to the folks at Logitech (and to every other keyboard maker out there), “You’re doing it wrong!”

What does ‘cordless’ mean?

This is a cordless keyboard. What does that mean? Think about it. If you have a keyboard with no cord, where does it go? It goes in your lap, of course. Or on your knees, or maybe balanced on one arm of your office chair.

It doesn’t just sit on your desk in front of your laptop, looking cool with no cable. Wireless devices in general can be used farther away from the terminal, in stranger and more convenient and incredibly awkward locations. (In the middle of a power outage, I once had a customer using a cordless mouse on my back.)

And using a cordless keyboard as a “laptop” keyboard should mean certain things. In particular, it should mean that the design engineers spent some time optimizing the design for its likely use.

But clearly they haven’t. Because every cordless keyboard I’ve seen, until recently, looked like a slightly shrunken corded keyboard. “Wow! I left my enormous keyboard in my pants pocket, and mom put it through the wash. Look! The cord is gone and it shrunk by about an inch. Neat!”

Folks, the fact is that I will probably never use that numeric keypad on the side of your keyboard. I have a separate numeric keypad that I use for my expense reports. That’s a relatively new product, too, and it’s still not perfect (you need arrows and numbers at the same time when you’re doing spreadsheet work, idiots!) but that’s a different blog post.

So why does every “cordless” keyboard have a number pad? Because if it didn’t, someone might claim more keys than us? I have no idea why, but here’s the problem: that number pad unbalances the keyboard!

Do the math. The keypad takes up what, four inches of space on the right side of the keyboard? And so as a result, the center of balance of the keyboard is two inches farther off than it should be. Because that keyboard is going to be in somebody’s lap!

Talk to your ergonomics people. Most of your users have arms that are about the same length. And so the “natural” position for a keyboard is to have the left-hand keys and the right-hand keys about the same distance away from the left and right hands, respectively.

Putting the arrow keys and the numeric keypad and the whatever-other-stupid-things out there on the right side of the keyboard makes the thing harder and harder to balance on your lap. And it moves the actual keys that people type with farther and farther ti the left, away from the hands that want to use them.

So please, keyboard guys, build me a keyboard. And twist those keys. Don’t just give it a nice “wave” shape, because that crap only works on the desktop. A keyboard for my lap needs to admit that my belly will prevent my hands from being anywhere near the “center” of the keyboard. So twist those keys 40 degrees or so – you’ve got a lap, you do the math. But remember, only “good girls” keep their keyboard on their knees. And there’s about two girls, good or otherwise, in programming. The rest of us keep that keyboard on our thighs, so we can prop our feet on the desk.

Then get rid of the keypad, or at least make it a separate unit. (I’ve already bought one of those.) And move the arrow keys and all the other nonsense. Make ‘em close to the edge, or down where laptops put ‘em, or something. But they have to be easy to use!

What I’d like to see added is a scroll wheel. I write code for a living. And when I’m not writing code, I’m writing documents – design documents, trip reports, recommendations, and even the occasional blog post. So I spend a lot of time going up and down in documents. I don’t want a touchpad. I hate touchpads. But if you could take the scroll wheel from a mouse and put it in the middle of the keyboard (in the V gap where you twisted the keys apart) that would rock.

And finally, let’s get old-school. Remember the Gateway AnyKey keyboards? If you design guys still want to put some keys on, I’d like some more function keys. Those of us who live in IDEs like Visual Studio or Eclipse have got too many options. Put some G-keys on the left. Put some H-keys on the right. Whatever it takes. But remember to keep the center of balance the same. If the keyboard grows by an inch on the left, then grow it by an inch on the right, too!

But I’m doing unit testing, and writing unit tests. In this case, I’m using the boost C++ libraries. That means my tests don’t look like classes, the way they might look if I was using CppUnit or CxxUnit. Instead, they look like macros:

BOOST_AUTO_TEST_CASE( null_ctor ) {

Arena & sut = Simple::Arena();
BOOST_CHECK( sut.capacity() != 0 );
}


The macro expansion is really quite clever, in a Lovecraftian “there are secrets man was not meant to know” fashion. And reading them has certainly improved my knowledge of C++. (But it also permanently lowered my SAN by a few points, I think.)

Anyway, Doxygen offers this command called \test that seems tailor-made for testing.

Well, it’s not. The command description is very “vague,” in that you use it to add entries (paragraphs) to the “test list.”

Some experimentation will show that the apparent use is to document something (a class, a function) and add a bunch of these \test entries, just like adding \param commands. And the entity you are documenting will then have a Test: section in its documentation.

This is totally not what I want. And I’m pretty sure it’s not what anybody doing TDD wants. What I want is to somehow tie my tests, which are in a separate location (different file, different class, different namespace, etc.), back to the class or function that I’m testing.

The best way I’ve found so far to accomplish this is to lie to Doxygen about what is being documented. Here’s my current scheme:

#define BOOST_TEST_DYN_LINK
#include <boost/test/unit_test.hpp>

Arena & sut = Simple::Arena();
BOOST_CHECK( sut.capacity() != 0 );
}


Adding the \class command tells Doxygen to re-open the documentation of the target class. The \test command is then associated with the “right” class, and I include the testcase name in bold as part of the test description.

This still doesn’t generate a link to the right source file (containing the test), and it doesn’t really know anything about the test case. So it’s not a perfect solution. But it does enable me to put my testcase documentation with my testcases, while having the documentation actually show up attached to the right class.

So here’s which.cmd – a script that tries to DWIW.

Note that this script is wrong in one key detail: it searches inside-out. That is, any “foo.COM” will take precedence over any “foo.EXE” even if the .exe version occurs earlier in the PATH.

@echo off
REM Copyright (c) 2010, Austin Hastings.
REM This file may be used for any purpose without restriction.

REM NOTE: This script does not handle multiple entries with different
REM extensions correctly. It returns the first matching EXTENSION, rather
REM than returning the first DIRECTORY with any EXTENSION.

REM Analogous to unix 'which' command, look for a matching runnable
REM in %PATH% and print the location.

SETLOCAL ENABLEDELAYEDEXPANSION

set check_extensions= ;%PATHEXT%

:ext_loop
if "%check_extensions%" == "" goto done

for /F "tokens=1* delims=;" %%E in ( "%check_extensions%" ) do (
	set check_extensions=%%F
	set target=%1%%E
	for %%W in (  !target! ) do set answer=%%~f$PATH:W
)

if "%answer%" == "" goto ext_loop

:done
if "%answer%" == "" goto not_found

@echo %answer%
goto exit

:not_found
@echo No runnable matching '%1' was found.

:exit

(On the other hand, if you’ve got one that needs special treatment, drop me a line and I’ll add it here.)

if which git > /dev/null
then
	parse_git_path() {
		if [[ -d .git ]]
		then
			git branch --no-color \
			| sed -rne '/^\*/s/^\* (.*)$/(git:\1) /p'
			return 0
		else
			return 1
		fi
	}
else
	parse_git_path() {
		return 1
	}
fi

if which svn > /dev/null
then
	parse_svn_path() {
		if [[ -d .svn ]]
		then
			local rroot=$(svn info | sed -ne 's/Repository Root: //p')
			svn info 		\
			| sed -rne "s#^URL: $rroot/(trunk|branches/[^/]*).*#(svn:^/\1) #p"
			return 0
		else
			return 1
		fi
	}
else
	parse_svn_path() {
		return 1
	}
fi

parse_vc_path() {
	parse_git_path \
	|| parse_svn_path
}

export PS1="\[\e]0;\$(parse_vc_path)\w\a\]${debian_chroot:+($debian_chroot)}\$(parse_vc_path)\w\$ "

The key is that bash performs command substitution on PS1 each time it prints it, so you can have whatever command sequence you want get run. In this case, it’s a script that does whatever processing is needed in order to determine the “branch”, if any, that you’re on.

But it made me think: how come Microsoft hasn’t just solved this problem already? Two “stacks” would wipe out the overflow attack problem at minimal cost.

Back Story

If you don’t know, here’s a very (!) short summary of the problem.

Computer software uses “subroutines” to do everything. In fact, even the “main” program is a subroutine. Because subroutines can call other subroutines, they can “stack up”. That is, “main” can call “sell ticket” which can call “print schedule” which can call “draw table”, etc.

What’s a stack?

In modern systems, there is no really good way to keep track of how many routines will get stacked up, a general-purpose data structure called a “stack” is used. This is so important that CPU’s explicitly support a single “call stack” with special CPU instructions like push and pop, special registers to access the stack, and all kinds of incredibly expensive stuff.

A stack works by “stacking” data, in much the same way they stack plates at a buffet restaurant (or cafeteria). The only data item you can get to is the one at the “top” of the stack. (The only plate you can take is the one on the top of the stack. See?) If you want to put on more data, it goes on the top of the stack, and the stack grows. If you want to take off data, you take it off the top of the stack, and the stack shrinks.

In this case, though, there are two ways to think about what “data” means. One way is to think of data as being individual units. One number goes on the stack, then another number goes on top of it, etc. But another way is to think of data “sets” going on the stack. If you think about the back button on your web browser, it acts like a stack. You click on a link, and a page gets pushed on to the “history” in the browser. You click “Back” and a page gets popped off the stack, leaving a different page visible in the browser. But these pages aren’t just a single number. There’s a URL, the page contents, maybe some form data, etc.

In terms of computer subroutines, each subroutine may have some “local data” that it needs to store. The URL of a web page, or the name of the current user, for example. And this data is expected to be used within the subroutine, maybe passed down into any sub-subroutines that get called, and then it will disappear when the subroutine finishes.

So a subroutine may have a bunch of local data, much like a web page in your browers. That can also be managed as part of a stack, using what is called a stack frame. A stack frame is a collection of data that all gets jammed onto the stack at one time, so the subroutine can use it. Again,”modern CPUs” (pretty much all of them built since the 1970’s) support this directly.

How important is the stack?

The de facto standard computer in the world today is the Intel x86 CPU of some kind: Pentium, Opteron, whatever you want to call it. Back when dinosaurs roamed the earth and nobody thought a 16-bit computer was worth the extra money over a 8-bit computer, the x86 family had about 30,000 transistors on board. Now, when people are arguing the relative merits of 32 versus 64 bit computing, the transistor count is about a billion.

The x86 family of computers work using “registers.” A register is a place in the center of the CPU where a number can be held while other stuff gets done to it. If you want to add two numbers, you use a register. If you want to store the result, you probably use another register. They are absolutely crucial to the design of the x86, and most other widespread CPUs. (There are alternative architectures: stack based and accumulator based CPUs. But nobody buys them except for special applications.)

The x86 registers back in the time of the 8088 and 8086 computer were called:

• AX The accumulator register, best for math.
• BX The base address register, best for pointer references.
• CX The counter register, best for loop counts.
• DX The data register, used for multiply/divide operations, I/O operations, and indirect addressing.
• SI The source index register, for memory-to-memory block operations, like copying data.
• DI The destination index register, used for memory block operations, like SI.
• BP The base pointer register, used to point to the base of the stack frame.
• SP The stack pointer register, used to point to the current “top” of the stack.

There were some additional registers, like IP, flags, CS, DS, ES, and SS. But they weren’t (and still aren’t) general purpose registers, can’t participate in computations, and generally don’t get modified much by programs. Because the registers listed above are general purpose registers, they can be used for things not listed above. For example, if you need to store a temporary intermediate result while you are computing some other value, you can always jam it into the DI register. (or SI, or DX, or whatever you like). But not BP or SP.

So back in the day, when we had to carve our own computers out of rocks using nothing buy a bronze chisel and a wooden mallet, BP and SP were given over to the stack frame. That’s two registers out of eight — 25%, for you liberal arts majors — assigned to do the job of keeping track of the stack.

And now?

When the 80×86 family went 32-bit, the registers changed. The 32-bit registers were called “extended” registers, and so the names became: eax, ebx, ecx, edx, edi, esi, ebp, esp.

Now, with the advent of the 64-bit x86 family, the names have changed again: rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp. But in addition, AMD added 8 new registers to the x64 architecture, and Intel followed suit.

This means that if you’re using a 32-bit CPU, or a 64-bit CPU in compatibility mode, you’re using 8 registers, still, and 2 of them are dedicated to the stack, still. (25%, still, for you liberal arts majors.) If you’re using a 64-bit CPU in 64-bit mode, then you’ve got 16 registers (that’s 12.5% for all you Art History grads).

So the stack frame, and the stack pointer, and this whole stack “thang” are pretty important.

What’s a buffer overflow attack?

So there’s a stack, and your subroutines use it. The most obvious way they can use it is to store a “return address” on it. If you have a subroutine called sub_1, it might have the stack set up like this:

    :
  ????
  ????
  1234 < -- SP

Where the SP (stack pointer) points to 1234. What's 1234? Well, it's the return address -- an address is a location in computer memory -- where it will send program control when it finishes doing whatever it is doing.

And if the sub_1 routine calls a sub_2 routine, the stack will look like:

    :
  ????
  ????
  1234
  1299 < -- SP

When the CPU executes a call instruction, it pushes the return address (of the instruction right after the call) onto the stack automatically. (And yes, on Intel platforms the stack always goes down instead of up. Don't ask why, it doesn't matter.)

When the sub_2 routine returns control to sub_1, it pops the stack and uses the address that it gets to branch back.

    :
  ????
  ????
  1234 < -- SP
  1299

Of course the 1299 is still down there -- it doesn't get erased. Instead, the SP adds 4 (4 is the size of a return address on a 32-bit [4 byte] CPU) and we go on. Very efficient, very fast, and very automatic with all the special instruction support.

Stack Frames, redux

When the program has local data it needs to store, the situation gets a little more complex. The caller pushes a return address, then the callee (the local subroutine) moves the stack pointer a little bit more, to make room. If sub_2 needs 12 bytes of storage, the preamble of the subroutine looks like this:

   push(ebp)
   ebp = esp
   esp = esp - 12

A preamble is a standard set of code that gets executed at the top of every function. It is generated automatically by the compiler — programmers don’t have to think about inserting it.

When it comes time to clean up and leave the subroutine, the corresponding code is the postamble and it does something like:

   esp = esp + 12
   pop ebp
   return

(In fact, this is wrong. But the effect is the same and it’s easier for you to understand.)

Before the subroutine is called, the stack looks like:

    :
  ????
  ????
  1234   < -- SP

Then when the call happens, the stack looks like:

    :
  ????
  ????
  1234
  1299  < -- SP

Then when the preamble runs, we get:

    :
  ????
  ????
  1234
  1299
   BP'  < -- BP
   ?
   ?
   ?     <-- SP (12 bytes = 3 x 32bit words of "stack frame" storage)

Note that the new BP is pointing to the place on the stack where the previous BP was stored.

So?

So there's a stack frame, and it's a little complex, and it's sitting there on the stack. And in the middle of that stack is the "local data" the subroutine needs.

Sometimes the "local data" includes what is called a "buffer." A buffer is just a space to store a bunch of characters in a row. For example, if the program is going to ask me for my name and address, it needs a place to store however-many characters go into a name and address.

If the buffer is 12 bytes long, I could enter my name as "Austin" and there would be not problem. But if I entered "Austin Hastings" (14 letters, with the space) the buffer would not be long enough to store the name. The problem is that if I am allowed to just enter any old thing, I might deliberately do something destructive. Suppose we are using our previous example:

    :
  ????
  ????
  1234
  1299
   BP'  < -- BP
   ?
   ?
   ?     <-- SP (12 bytes = 3 x 32bit words of "stack frame" storage)

If I type my name as "Austin Hastings", the buffer overflows, like this:

    :
  ????
  ????
  1234
  1299
  ngs   < -- BP
  asti
  in H
  Aust  <-- SP

The old value of BP gets wiped out, and so the calling subroutine will have a bunch of bogus data (because it accesses all the local variables relative to where BP is pointing).

But if I type my name as "Austin Hastings.1215" look what happens to the return address that is supposed to point to the subroutine that called us:

    :
  ????
  ????
  1234
  1215    -- look here!
  ngs.   < -- BP
  asti
  in H
  Aust  <-- SP

See? The return address got changed by me typing in a special, too-long name. This is called a "buffer overflow attack", and if done right it can cause the subroutine to return control to a new program, written by the attacker.

Why can Microsoft solve the problem?

First, Microsoft writes Windows, the most attacked system in the world. And it writes the Microsoft C/C++ compiler, which is the tool of choice for compiling on Windows. Since anything Microsoft does will get copied by the Linux and Apple guys, this is a no-brainer. If Microsoft solves the problem, everyone will copy them and solve the problem for their own sites.

Okay, how can Microsoft solve the problem?

The solution to the "attack" part of the problem is to use two stacks. There are two registers already, and one of them rarely gets used (SP). So split them into two different stacks, and you eliminate the ability of an attacker to overwrite the return address (by separating the stack frame data from the "just-a-stack" data).

Details

Here's what the previous example would look like with two stacks.

  "Frames":          "Stack":
      :                1234
    ????               EBP(1)  < -- SP(2)
    ????  <-- BP(2)    1299
    ....               EBP(2)  <-- SP(3)
    ....
    ....  <-- BP(3)

Notice that I've drawn the buffer as dots, and whatever was in the caller's local data as question marks. Notice also that the important data -- the frame pointers and return addresses -- are in a totally different place from the stack frame data. This means that no buffer overflow attack can reach them.

That's it?

Yep. That's it.

Mind you, it's an expensive it. But not a horribly expensive one. Microsoft, and the GCC folks, and Intel, and anybody else that writes a compiler, would have to come up with a transition plan to take us from one system to another. It would probably easier for Microsoft, since they can deliver their system (Windows) all at once. This recompile would have to happen for almost every problem, so it might take a while for total coverage. But the "most attacked" programs are things like email servers, web servers, the PHP interpreter, etc. There is a pretty short list of those, and getting them secured might take an hour and a half, if everyone would work together.

Any problems with this idea?

First, it doesn't just magically make everything work. Some solutions, like W(+)E, try to do that. If you can just "solve it in hardware" then the problem goes away without messing around with that 23-year-old program that the boss uses but nobody has the source for.

Second, this approach doesn't require anybody to buy a new computer. (But keep reading!) So unless Microsoft forces an upgrade with Windows 7 or 8 or whatever (and when have they ever forced an upgrade?) there's no money in it for the CPU vendors.

Also, don't forget that this only protects against buffer overrun attacks that try to force code execution. It won't protect you from corruption of data that is in a stack frame buffer or local variable. Someone might try to rewrite their account balance, or change your password, or whatever.

Checksum the Stack Frame

There's a solution for that, too. And it could involve new hardware. Just create a "checksum" value for the stack frame, and put it right at the end of each subroutine's frame. That way, if an attacker overruns a buffer it will destroy the checksum.

Obviously I don't mean a real checksum. What I mean is something unpredictable, unlikely to occur at random, and easily checked. Most of the registers wouldn't work, since their values are generally predictable. It would make sense to create a dedicated register for this on the CPU -- which would also allow Intel to make some new hardware -- and push the "random" value on both the frame stack and the SP stack (for checking).

If you're so damn smart, why aren't you rich?

I used to do a lot of assembly programming. So I've always kind of wondered why this wasn't obvious to everybody else. And it may well be that there's some critical flaw in the logic. Probably having to do with interrupt-proofing the two-stack transition.

But maybe there's not. Maybe it's just obvious to me. In which case, I hereby demand that anyone who implements this must call it "Austin's Device". And if you implement the checksum idea, that shall be "Austin's Other Device."

But there's an old joke about an Economics professor and one of his grad students walking across the quad. And the grad student says, "Look, professor! There's a $100 bill lying on the ground."

To which the professor replies, "Don't be absurd. If there were really a $100 bill lying on the ground, someone would pick it up."

Maybe you know what's wrong with my clever device? If so, please let me know. ]]> http://www.longacre-scm.com/blog/index.php/2009/06/why-not-2-stacks/feed 0 http://www.longacre-scm.com/blog/index.php/2009/06/things-left-unsaid http://www.longacre-scm.com/blog/index.php/2009/06/things-left-unsaid#comments Sat, 27 Jun 2009 23:15:18 +0000 Austin Hastings http://www.longacre-scm.com/blog/?p=69 In my copious spare time I’m working on a programming language called “Close.” It’s a C-like systems programming language targeted at the Parrot VM.

Now, I’m not a compiler guy. But I don’t have to be. Because Parrot comes with the Parrot Compiler Toolkit (PCT), a set of code that can render an Abstract Syntax Tree (AST) into executable code. The result is that I built a grammar using Perl6, then wrote some action methods hooked to the grammar that built the AST. Then I stood back and let PCT do it’s voodoo. The time between starting the project and now has been about 3 weeks, and I was busy with other stuff for 30 percent or so of that.

Okay, that’s cool. Parrot+PCT rocks, as Allison Randal points out. But it’s not my point. The reason I wrote Close was because people were still coding in PIR — Parrot’s version of assembly language — years after starting the project. D’oh! Everybody knows that the first thing you do with a new architecture is develop a C compiler.

Well, somebody had to do it. So I stepped up. I talked a little bit about it at the Parrot Virtual Machine Workshop last week in Pittsburgh, and some other people acted interested. As a result, it’s up on Google code at http://close.googlecode.com. But the key for me was a conversation I had with Uri Guttman in a hallway at YAPC10 (the conference to which the PVMW was attached).

I showed Uri this code:

void test_foreach()
{
	pmc the_list = new ResizableStringArray;
	push the_list, "alpha", "beta", "gamma", "delta", "omega";

	pmc new_list = new ResizableStringArray;
	int count = 0;

	foreach (str i: the_list) {
		push new_list, i;
		++count;
	}

	ok(count, 5, "f/e Iterate over each element");

	count = 0;
	int pass = 1;

	foreach (i : new_list) {
		if (i != the_list[count++]) {
			pass = 0;
		}
	}

	ok(pass, "f/e Same items, same order");
}

And Uri read through it, figured out what I was doing, and said, “Well, I don’t like your coding style. And I really don’t like single letter variable names, even inside a loop.”

And my first reaction was “Up yours, bud!” But I swallowed that, and then it hit me: I won!

The whole point of implementing Close was to stop writing code that looks like this:

.sub 'uniquereg' :method
    .param string rtype
    unless rtype goto err_nortype
    if rtype == 'v' goto reg_void
    .local string reg
    reg = 'P'
    $I0 = index 'Ss~Nn+Ii', rtype
    if $I0 < 0 goto reg_psin
    reg = substr 'SSSNNNII', $I0, 1
  reg_psin:
    reg = concat '$', reg
    .tailcall self.'unique'(reg)
  reg_void:
    .return ('')
  err_nortype:
    self.'panic'('rtype not set')
.end

And so what occurred to me was that I showed Uri some code that didn't look like that. It looked like C. And so naturally he read it. And he commented on something that was relevant to him. Not "Gee, I can read your code!" but "Of course I can read your code -- it's C. But I don't like your curly braces."

Win. Win. Win.

Hearing what Uri did not say was the key.

Brad Appleton is, in my opinion, one of the all-around smart guys in the CM space. His focus for the last few years has been on Agile CM, but his writings are applicable to anybody doing software development, for a very broad definition of software – most of what he writes is applicable to almost any kind of intellectual property. And recently Brad has been doing some blogging about books on various flavors of ‘trust. ‘

Trust, to me, is one of those core values for most CM specialists. The fact is that CM is a simple job. There are certain requirements, and once you meet them you get to go home. In that way it’s a lot like being a system administrator: is the system up, is everything working? Okay, go home. Now admittedly it can be pretty hard to meet some of those requirements. That’s why I didn’t say it was an easy job – just a simple one. But that’s where trust comes in. Because whether your shop is an agile shop or not, the CM guys are more affected by trust than any single other thing.

Let me repeat that: CM guys are more affected by trust than any single other thing.

I’m a CM consultant. I get called in by shops that either don’t have CM and want to build a team, or by shops that already HAVE a CM team but have experienced enough CM failures that they don’t trust them any more. Since most companies obtain headcount by calling up a body shop and ordering it by the pound (kilos for the EU, I guess), I don’t usually get called first for CM team setups. It’s usually only after there are some bodies on site, when it turns out that CM specialists that are great at keeping an existing system going don’t have so much experience in starting a new system up from scratch. So there’s usually some kind of mess on the floor when I show up.

What does that mean for you? Well, it means that if you see me at your shop, you should make sure your resume is up to date. (Sorry, but it’s true.) It also means that you can keep me, or somebody like me, from showing up if you concentrate on building trust with your customers.

Brad’s first blog post about trust was on Covey’s “The Speed of Trust,” and in that book there are five “rings of trust” outlined. The second and third rings, or types, are interpersonal trust and organizational trust. That’s where I live, and if you’re smart it’s where you spend time each day maintaining your relationships with your customers.

It’s a pretty simple set of questions, but it makes all the difference.

1. Do the people you interact with understand what you need from them, and understand how to deliver it?
2. Do they understand what services you can provide to them, and how to request them?
3. Are all of these things practicable?
4. Do they perceive you as doing what is needed, on time, and without unnecessary oversight?
5. Do they perceive you as requesting things that are objective, and consistent, and in keeping with your and their function?
6. Do they believe the estimates and the explanations you give them?

If you can answer yes to all of those, you’ll never work with me. That’s because your customers trust you. If you can’t – if your customers distrust you – then as the level of trust decreases, the likelihood of a “fixer” being called in for your team goes up. In the credit card business, your interest rate goes up. In the CM business, the level of interest in working with you goes down.

If you’re a CM manager for a military systems contractor, then you’ve got a CM plan. And you’ve got a set of prescribed deliverables. And if the developers – software, firmware, systems engineers, whatever – know how to deliver each release to you, and it’s an automated, mechanical, simple chore, then you’re halfway there. If your other customers – the clients, and the development team that need to roll back to an earlier release – can submit a request and quickly get some kind of link, or bundle, or set of typing instructions, then you’re all the way done.

If you’re a build guy, or a release guy, or a deployment guy for a software team – agile or not – then the activities might be different but the questions aren’t. Does the team know how to get you to do a build, or cut a release, or deploy a package? Are there any bogus hoops they have to jump through? Have you built any passive-aggressive walls, saying “we want the development team to do this thing which they really ought to trust us to do but they overrode us that one time and now we’re bitter and whiny and nobody loves us”? Can a developer quickly get to the codeface of some old branch from six months ago?

I guess the short form is this. Are you doing your job? Are you making it as easy as possible for your customers to ask you to do your job for them? Because in my experience – and I’ll admit my experiences are all negative – if you aren’t doing your job, or if you’re making your customers pay some kind of “tax” (time, whining, paperwork, hoop-jumping, sloth, inefficiency) then you’re going to lose trust. And once you lose trust, you’ll see a little bureaucracy get started. And when that doesn’t work (and it rarely does) you’ll get to meet me. I’ll be the guy “we brought in to help gets things caught up.”

This isn’t a threat, quite. Because I don’t know you. It’s a reflection of the world as I see it, because I’m like a specialist doctor – nobody makes an appointment with a gastroenterologist to talk about how healthy they are. In my case, nobody calls me up and says, “We’d like to pay you to fly out here and sit in a conference room and live in a hotel for two weeks so that we can tell you how smoothly our build and deployment works!” (Man, I would LOVE that.) But what I get instead is, “We need you to come and fix our build and deployment procedures. Our developers don’t trust the CM team, and we’ve had a couple of blown deployments in the last few months.”

So anyway, I guess the upshot of this blog post – and this is much too depressing to be a CM Journal article, so it’ll stay a blog post – is that you need to make sure your house is in order, trust-wise. Go read one or more of the books on Brad’s list. Because CM teams seem far more Boolean than development teams. Developers can say “It’ll be done soon,” while CM’ers have to say “it’s not done.” And saying “it’s not done” leads pretty directly to “you’re not hired.”