Reading (For Dummies)

Pascal's Paradox

A few days ago, a funny Seventh Day Adventist showed up on my door. He was a friendly enough fellow, and asked about my faith. "Atheist," I said, "and anyone that tries to tell me otherwise is probably trying to sell something."

Yeah, I like the Princess Bride. He scribbled this down in his notebook. Great, I'm probably on some kind of "prayer list" or something.

"Really?", he asked. "How can all of this subjective experience be just nothing?"

"Simple," I said, "I live my life, and then I die, and then there is nothing left to experience."

"What do you think Jesus was: son of god, historical figure, or work of fiction?"

"Probably a historical figure, but fiction seems more plausible at times."

"Well what about the objective reality?"

Obviously my time in government service left me entirely too...sober. I was growing impatient. "Look," I said, "I go through life and question every piece of information that gets thrown in front me. I don't win a lot of friends, but I do make a difference."

"You're familiar with Pascal's Wager?" he asked

Yeah, Pascal's Wager. I could use the official church jargon to explain why it is a retarded bet, akin to playing Russian Roulette (it's also a lot less exciting than Russian Roulette, I imagine). Instead, I argued with reason. "Religious people waste their entire lives praying and bowing and hoping things will happen. I make things happen, because I know that only people can make things happen. That is the fallacy of Pascal. Hope."

So today, I put my money where my mouth is. One of Laura's co-workers, Pablo, is from Chilé. His brother lives in a small town outside of Concepcion, as close to the epicenter of today's quake as possible. Pablo can't reach anyone in his family (most of his family lives near Santiago). I decided to donate my last paycheck to the Red Cross. Yeah, I probably can't afford it right now. I'm no saint, either. But money, more than prayers (or even yoga mats), is what folks in Haiti and Chile need right now.

Green Hills C Compiler bug

I had a rather proud moment a few days ago. I had been looking at a curious piece of compiled code that had an integer promotion bug. Yeah, I have some pretty weird hobbies these days. This particular bug was for the Motorola Coldfire processor. The C code, it turns out, looked like this:

unsigned char table[256] = {0xsomevals} // global array, located on process heap
unsigned char array_lookup(unsigned char uc){
return table[(unsigned integer) uc];
}

The compiler compiled the code (the function part of the above) into something like this:

link a6, #0
;; there would be a 'store registers' command here', I don't remember the syntax at the moment
;; stw.l (a0,d0), (-sp) ?
move.l -4(sp),d0
mvs.b d0,d0 ;; offending line
move.l (0,d0+a0),d0
unlink a6, #0
;; there would be a 'restore register' command here, again I don't remember syntax
rts

For the coldfire assembler unaware, the mvs operation is "move with sign extension". The effect is that the function can return memory logically *before* the array. If the unsigned char passed in is 0x80 or greater, the most significant bit of the byte is a '1'. The sign-extended move operation makes the index value negative. What is interesting here is that the compiler ignored the explicit unsigned integer cast when it dereferenced the element in the array.

It turns out that this was a bug in an older version of the Green Hills compiler. Newer versions don't exhibit this erroneous behavior. I have no information on what versions of the Green Hills compiler are affected by the bug, but if you are a vendor programming Coldfire V4 cpus (mvs was introduced in the Coldfire V4 instruction set), you may want to compile my above code snippet and make sure that your compiler is not affected.

I have to say that I was kind of impressed with myself for finding the bug. The people that produced the compiled code were kind of dumbfounded as to how I stumbled upon it. Since I have started exploring embedded systems security, I've decided that the C language is probably one of the most wretched things in the universe, and that embedded system vendors ought to use as much as peer-reviewed code (read: open source) as possible in their systems. Here I mean both compilers and process code. C compilers for these systems generally don't receive as much scrutiny as desktop application compilers, probably because the target processors are not x86.

Hacking Traffic Signals

I noticed something funny on my walk tonight. The traffic signals in Pullman are timed funny for pedestrians.

I've always lamented how horrible "downtown" Pullman is for pedestrian traffic. Smash a crosswalk button and you often have to wait for 5 minutes for the lights to change. Most of our intersections have traffic flow sensors on the signals (cheesy little things, I honestly have no idea how they work). I sat at one intersection and tried a few experiments to see how the traffic flow affected crosswalk time.

Experiment 1: Hit the button while traffic is flowing steadily through the intersection. Time to light change (and my 'walk' sign lighting up): 3:30.

Experiment 2: Hit the button while one car is going through the intersection. Little to no traffic following this car (two more cars went through the entire time I waited for this change): 3:30.

Experiment 3: Hit the button while no traffic was flowing through the intersection. There was a ten second gap in traffic. The light changed in 0:15.

Conclusion: The traffic algorithm at this particular intersection is retarded. It must measure traffic flow at the moment the 'walk' button is hit, and decide how long to wait based on that single measurement. As a pedestrian, you should wait until there is a small break in traffic to hit the walk button. You'll probably save time by not hitting the crosswalk button right away...