Friday, August 13, 2010

Oracle sues Google over Android

I guess it shouldn't be too much of a surprise.  Android gets big enough and it'll attract lawsuits... Oracle is suing Google over some of the contents of Android.  Google's reimplementation of Java through it's Dalvik VM and Android's success obviously makes Oracle want a piece of the action.

The specific patents involved: 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; and 6,061,520.  Oh, and they also claim copyright infringement to boot.

Is this a legitimate lawsuit?  Is Google going to have to retract portions of Android or Dalvik?  I could see Google trying to out-technology Oracle to solve the patents just out of spite, even if that has a big slowdown to the growing Android community.  I don't know, and I'm not a lawyer.  But I did read through the patents involved, and it seems that there are three groups of complaints.

One is on security mechanisms and resource protection of Java.  That one seems like it will be hard to defend against, since Dalvik mimics much of the Java mechanism.

The other is on how class files are processed and packaged.  My guess is that Google could probably get around this one without too much trouble by redoing their tools.  You already have to recompile Java anyway for Android, why not redo how class files are handled?

The third area is around how the VM optimizes instructions. Parts of the claimed patents seem easy to avoid, but others do not.  This could be a difficulty to work around, but I'm not certain.

Of course Google's other option is just to pay Oracle off.   Would Oracle ask for an injunction on shipping Android devices to spite Google?  Don't know.  Either way, I suspect there will be interesting times ahead for the Android ecosystem.

Monday, August 9, 2010

Lies, Damn Lies. (or, QNX was *not* hacked in a car.)

A colleague of mine pointed me to this blog from Dave Kleidermacher, which, although hosted on the EE Times website, sounds suspiciously like a GreenHills ad:
“Hello, I’m a VxWorks device. Would you like to own me?”

Dave makes some "interesting" claims in his blog.  Here's a quote:

This may sound eerily similar to my car hacking blog which discusses how a diagnostics port was used to subvert a car’s brakes and engine. What I didn’t mention then is that this hacked system also runs an RTOS: QNX. 

Hmmm.  Sounds damning, doesn't it?  He follows this with an immediate pitch for a GreenHills Security Kernel product.  I work for QNX, so I just had to look further.

I read the actual academic report that he bases his "information" on. Dave apparently doesn't understand cars or doesn't understand what problems his own company's product is supposed to solve.  The reasoning  used to implicate QNX by interpreting the academic report is faulty at best.  The premise of the study is that with an OBDII tool you can send arbitrary messages on the vehicle bus.  Since every car has an OBDII port (by government mandate for emissions monitoring and control), you can "hack" into every car.  This "hacking" allows you to do all types of things to the car, from shut off the engine, control the brakes, reflash the telematics unit, etc.

In a word (or maybe two), "no duh".  When you bring your car into the dealership, how do you think the techs communicate with it?  They don't whisper it back to health!  The paper describes doing things to the car while moving: they've set up a laptop with WiFi that they've plugged into the vehicle bus while driving along side in a chaser car.  Not exactly something that is practical without physical access to your car.  One of the things done in the hacking test is to replace the telematics unit firmware (the module running QNX) with a custom firmware image that lets them transfer messages between the low-speed and high-speed CAN buses as a bridge.

Oh my goodness!  How could QNX allow a hacker to replace the RTOS firmware image?!  In fact it's not a surprise, because that requirement is written into the specification.  That's right.  For a dealership to update the modules within the car, those modules need to be able to be reflashed.  Every module has this requirement. I don't care if your car module is running the QNX Neutrino RTOS, or the QNX Neutrino RTOS Safe Kernel, or the GreenHills Superfragilisticexpialidocious kernel or Kumquat OS 9.9.  If the module is actually operating properly, it will allow itself to be reflashed. Period. The purported problem cannot be solved by use of a security kernel whether from GreenHills or anybody else.

The true problem being pointed out by the academics is that the car vehicle network, for better or worse, was designed as if it were a closed system.  The only thing that prevents malicious mischief is the difficulty of gaining physical access to the vehicle bus connectors.  I would agree that vehicle buses probably need to start considering authentication / identity verification / challenge / response protocols in their design. Because the dealers will always have the requirement to fix/diagnose/update cars, they will have access to tools to let you do this.  No matter what you could design to solve the "closed network" problem, it can be abused by unscrupulous people.

Tuesday, August 3, 2010

GenIVI report slams QNX. Independent view seems to differ.

While Canada was sleeping (yesterday was the Civic Holiday in Canada), the GenIVI Alliance released a report that "predict[s] QNX will withdraw from the IVI market eventually. Questionable future is also due to lack of a consortium (such as GENIVI) to drive the architecture."

Seems a little self serving for GenIVI to state that we won't be successful because we're not GenIVI.  It's news to me also that we're withdrawing from the market, especially since we're hiring more people every day in support of the business we're continuing to grow.

Apparently the report doesn't hold water with independent analysts either.  Roger Lanctot in his Strategy Analytics blog disputes quite a few points in the GenIVI report as simplistic or overstating the facts.  He shows too that the report attempts to bolster the GenIVI point of view without providing any real evidence.  Interestingly enough, the GenIVI report claims that it interviewed people throughout the industry, including QNX.  I'd be interested to know who exactly they interviewed at QNX and what they contributed to that report.

The GenIVI Alliance publishes the summary report, but of course you can't read the full version of the report without joining GenIVI.  (No wonder they have so many members!  Maybe I should publish a slanderous white paper about GenIVI, but you have to join QNX CAR to read it :-)