Everyone's allowed a little self-promotion once in a while! Here's a video of me showing off a new QNX CAR feature: iPod Out Video
I don't think I'll be moving to Hollywood anytime soon!
Thursday, September 2, 2010
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.
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?”
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.
“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 :-)
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 :-)
Wednesday, July 21, 2010
QNX, BMW and Apple iPod Out
QNX has had a long tradition of being independent. When we were acquired by Harman International, a big automotive tier one (Harman Becker) suddenly became our sister company. Many of our automotive customers were concerned if we would still support them, since Harman Becker was one of their competitors. Non-auto customers were worried that we would just drop their market altogether. We proved our commitment to our customers with more than just words, and some of the most vehemently concerned customers eventually admitted that we were treating them even better after the acquisition than before. That is, more responsive, more proactive, more resources, and quicker technology rollouts.
After RIM acquired QNX, I expected another round of the same customer concerns about QNX and our continued direction. It really hasn't materialized, I guess because this time around everyone clearly sees that there is a very natural fit to RIM and QNX. About the only thing we hear these days is the occasional question from customers about whether or not we will still support the technologies they care about. An example is: "since Apple and RIM are competitors, are you going to continue supporting Apple devices?"
The answer is, of course "yes," but the proof in the pudding, as they say. How about this:
http://www.ubergizmo.com/15/archives/2010/07/bmw_to_support_ipod_out_in_the_future.html
Apple's iPod Out feature is a brand-spanking new feature that Apple just released in OS4 that allows an iPhone or iPod Touch to pump an Apple-customized video HMI to an automotive head-unit. It's not available in any production models today, and BMW is the very first car company to announce support for it. I'll give you just one guess which operating system is being used for this project. (And despite BMW's highly public Linux strategy, please don't waste your guess on GenIVI :-)
Although the feature is hot off the presses, here's a shaky-cam snapshot of our very own Mike Shane running the QNX Neutrino RTOS with a preliminary version of the iPod out feature integrated into our iPod driver.
After RIM acquired QNX, I expected another round of the same customer concerns about QNX and our continued direction. It really hasn't materialized, I guess because this time around everyone clearly sees that there is a very natural fit to RIM and QNX. About the only thing we hear these days is the occasional question from customers about whether or not we will still support the technologies they care about. An example is: "since Apple and RIM are competitors, are you going to continue supporting Apple devices?"
The answer is, of course "yes," but the proof in the pudding, as they say. How about this:
http://www.ubergizmo.com/15/archives/2010/07/bmw_to_support_ipod_out_in_the_future.html
Apple's iPod Out feature is a brand-spanking new feature that Apple just released in OS4 that allows an iPhone or iPod Touch to pump an Apple-customized video HMI to an automotive head-unit. It's not available in any production models today, and BMW is the very first car company to announce support for it. I'll give you just one guess which operating system is being used for this project. (And despite BMW's highly public Linux strategy, please don't waste your guess on GenIVI :-)
Although the feature is hot off the presses, here's a shaky-cam snapshot of our very own Mike Shane running the QNX Neutrino RTOS with a preliminary version of the iPod out feature integrated into our iPod driver.
Biking in Oregon
Although I've been back for a week now and the post-vacation buzz has subsided to a whisper, I thought I'd share a couple pictures from my recent trip to Oregon where I spent some time biking down part of the coast. It was a fantastic trip!
Friday, July 16, 2010
The key fob is dead! Long live the key fob!
Here's some food for thought. I was reading in the latest SAE about how key fob powers are becoming broader vehicle personalization devices. They are doing much more than just an unlock: remote start, rolling down windows, checking temperature, controlling vehicle seat settings, radio presets, colors, and almost any other preferences you can think of. The article by SAE goes on to quote Lear and talk about how they see the fobs requiring feedback so that you can monitor the vehicle settings remotely as well. To handle all these capabilities, they're bumping up the processors from 8-bit to 16- or 32-bit processors (can't say that I'm sad about that), as well as putting in small LCD screens.
Okay. Combine that fact with some other recent announcements. Like the smart phone apps from Chevy for the Volt or the OnStar smartphone app that lets you access your vehicle. Delphi makes a system today that right now uses a combination smartphone with a souped-up key fob and range extender.
It's not hard to see that key fobs as we know them are going the way of the dinosaur. Why on earth are you going to carry one more huge lump on your key chain when you've already got your phone? I predict that within the next 3 years, key fobs will be those extra-expensive optional add-ons that will be sold only to the severely technologically challenged. Everyone else will download their OEM's specialized key fob app into their smartphone. Those key fob apps will use WiFi, Bluetooth, or a cellular network to communicate with their vehicle--unlocking it, starting it, and setting it up specifically for you. Smartphone apps won't require additional hardware costs. And they're already an indispensable part of the everyman's (and everywoman's) arsenal.
I'm looking forward to the day when I don't have a key fob, but a key fob app.
Okay. Combine that fact with some other recent announcements. Like the smart phone apps from Chevy for the Volt or the OnStar smartphone app that lets you access your vehicle. Delphi makes a system today that right now uses a combination smartphone with a souped-up key fob and range extender.
It's not hard to see that key fobs as we know them are going the way of the dinosaur. Why on earth are you going to carry one more huge lump on your key chain when you've already got your phone? I predict that within the next 3 years, key fobs will be those extra-expensive optional add-ons that will be sold only to the severely technologically challenged. Everyone else will download their OEM's specialized key fob app into their smartphone. Those key fob apps will use WiFi, Bluetooth, or a cellular network to communicate with their vehicle--unlocking it, starting it, and setting it up specifically for you. Smartphone apps won't require additional hardware costs. And they're already an indispensable part of the everyman's (and everywoman's) arsenal.
I'm looking forward to the day when I don't have a key fob, but a key fob app.
Subscribe to:
Posts (Atom)
Posts
