Node.js running in the new Airbus A350 inflight servers(reaktor.com)
reaktor.com
Node.js running in the new Airbus A350 inflight servers
http://reaktor.com/blog/aircraft-customer-experience-on-a-new-level/
121 comments
I wouldn't be so quick to dismiss how avionics is done currently. That software operates against very difficult requirements, the industry has learned a lot about how to do so reliably. These systems favor static allocation over heap allocation, so a garbage collector isn't as useful as you'd assume.
Nothing against python, but it's just not suited to writing avionics code that human lives depend on.
Now, in some ideal future, could we be using better languages? Absolutely. Stuff like ATS looks like the future of that kind of code, IMO. Likewise, Rust's memory management types make a ton of sense and could be useful for the situations where static allocation can't do the job.
Nothing against python, but it's just not suited to writing avionics code that human lives depend on.
Now, in some ideal future, could we be using better languages? Absolutely. Stuff like ATS looks like the future of that kind of code, IMO. Likewise, Rust's memory management types make a ton of sense and could be useful for the situations where static allocation can't do the job.
With Rust I'd still be worried about compiler stability and destructor/allocation pauses. There's a reason that most avionics software written is on top of an RTOS & compiled with multiple different compiler vendor's software.
Not saying it couldn't in the future, but it pays to look backwards for safety critical systems.
Not saying it couldn't in the future, but it pays to look backwards for safety critical systems.
Personally, I prefer node.js for serving as a backend to a JS based front end... Then again, I also like document oriented databases most of the time (RethinkDB, Mongo, etc).
I find that there is much less distraction when you're working on both the front end and backend, that you can get things done much more seamlessly. In this case (for entertainment), I feel it's a pretty decent match.
For other systems, I'm not sure I'd suggest C variants at this point, if Go or Rust are options, I'd probably favor one of them. It really depends on the use case.
I find that there is much less distraction when you're working on both the front end and backend, that you can get things done much more seamlessly. In this case (for entertainment), I feel it's a pretty decent match.
For other systems, I'm not sure I'd suggest C variants at this point, if Go or Rust are options, I'd probably favor one of them. It really depends on the use case.
My only thought is that the airline is going to regret crumbling under the pressure from developers who wanted node.js. Allowing developers to choose whatever language they want for such a massive system is a mistake. node.js has not proven itself beyond being the latest fad. The developers wanted to use something cool and modern, while clearly ignoring concerns over the long-term viability of the system.
Oh well, that isn't a problem for anyone other than the airline. It's possible that in a matter of a few years (instead of decades), the entire system will have to be reimplemented at the airline's cost. You don't use the latest trendy language for systems which are expected to remain in operation for 20-30 years.
Oh well, that isn't a problem for anyone other than the airline. It's possible that in a matter of a few years (instead of decades), the entire system will have to be reimplemented at the airline's cost. You don't use the latest trendy language for systems which are expected to remain in operation for 20-30 years.
I'd rather use a statically typed language, like C++11 to avoid surprises at runtime. I guess you could use TypeScript to circumvent this problem.
You'd rather use a language full of undefined behavior as opposed to one in which (practically) every behavior of a program is specified by ECMA-262? To "avoid surprises at runtime"?
Surprises based on undefined behavior are usually not surprises at runtime, because of superior tooling. Either way, C is best because it has both of those things (tooling, defined behavior). It is possible to write very nice C.
> Surprises based on undefined behavior are usually not surprises at runtime, because of superior tooling.
Yes, they are. Empirically ([1], just to name one example).
> Either way, C is best because it has both of those things (tooling, defined behavior).
C has tons of undefined behavior.
[1]: https://lwn.net/Articles/342330/
Yes, they are. Empirically ([1], just to name one example).
> Either way, C is best because it has both of those things (tooling, defined behavior).
C has tons of undefined behavior.
[1]: https://lwn.net/Articles/342330/
I'm sure that you could use a high level language like Java or Python for some non-critical tasks. For more critical software you likely have hard real-time requirements, and you need to be able to reason about memory use and time in ways that obviously isn't suitable for anything that could "pause the world" for an arbitrary amount of time to collect garbage.
Exactly this.
It's not that there's anything wrong with using a high-level language for safety-critical systems with real-time requirements and limited hardware. It's just that every high-level language that's remotely appropriate for this set of requirements wasn't production ready (or even conceived of) 10-20 years ago.
Hopefully the next generation (or the one after that) of control software for aircraft will be written in beautiful code :-)
It's not that there's anything wrong with using a high-level language for safety-critical systems with real-time requirements and limited hardware. It's just that every high-level language that's remotely appropriate for this set of requirements wasn't production ready (or even conceived of) 10-20 years ago.
Hopefully the next generation (or the one after that) of control software for aircraft will be written in beautiful code :-)
What struck me was most is the ability to iterate quickly on features and bugs. They didnt just bring Node to the plane, they also brought a more modern software dev mentality. Node's ease of use and ecosystem are a definite asset there.
Most airlines are stuck with static, slow, and outdated in-flight systems. This will help them compete as consumers' devices have become embarrassingly better than the typical in-flight UX. Not to mention consumer devices are much heavier on bandwidth and power usage.
In regards to the other unsubstantiated comments in this thread, I would assume as an airline they also brought modern security practices along with the rest of the deployment.
Most airlines are stuck with static, slow, and outdated in-flight systems. This will help them compete as consumers' devices have become embarrassingly better than the typical in-flight UX. Not to mention consumer devices are much heavier on bandwidth and power usage.
In regards to the other unsubstantiated comments in this thread, I would assume as an airline they also brought modern security practices along with the rest of the deployment.
Fast-forward 20 years, a plane crashes, they find and open the black box and in the flight logs they can see the cause clearly:
"undefined is not a function".
"undefined is not a function".
Sure beats 'segmentation fault'
Not really; the latter is usually followed by "core dumped", and some amount of useful information written to the disk.
No that is simply not true, seg faults provide useful debug info in any potential core dump they provide.
Also, for something as important as an aircraft, I'd prefer to have a developer who knows what a seg fault is writing the code for any aviation equipment over someone who thinks "'undefined' is not a function" is equivalent to a seg fault.
Also, for something as important as an aircraft, I'd prefer to have a developer who knows what a seg fault is writing the code for any aviation equipment over someone who thinks "'undefined' is not a function" is equivalent to a seg fault.
> No that is simply not true, seg faults provide useful debug info in any potential core dump they provide.
I'm not sure I understand this. Can't you get a backtrace out of a JavaScript exception just as well as you can get one out of a segfault? The segfault itself doesn't carry any information other than at best the faulting instruction and the nature of the fault, and you can surely get that out of a JavaScript exception.
Furthermore, a segfault is very often a sign of memory corruption that has already happened, possibly in the stack frames themselves. "undefined is not a function" is not. JS code that crashes with that error is in a much more debuggable state than native code that crashes with a segfault. And you can certainly configure your interpreter to take a coredump on an uncaught JS exception, which will definitely be more debuggable than a coredump post-memory corruption.
(Your personal attack is not an argument.)
I'm not sure I understand this. Can't you get a backtrace out of a JavaScript exception just as well as you can get one out of a segfault? The segfault itself doesn't carry any information other than at best the faulting instruction and the nature of the fault, and you can surely get that out of a JavaScript exception.
Furthermore, a segfault is very often a sign of memory corruption that has already happened, possibly in the stack frames themselves. "undefined is not a function" is not. JS code that crashes with that error is in a much more debuggable state than native code that crashes with a segfault. And you can certainly configure your interpreter to take a coredump on an uncaught JS exception, which will definitely be more debuggable than a coredump post-memory corruption.
(Your personal attack is not an argument.)
Sorry its really not intended to be a personal attack and i regret the wording.
To clarify what I was trying to convey, the issue I personally find is that JS errors often produce difficult to understand descriptions and misleading traces when compared to some alternative languages.
I do believe that there is good work being done to convert these errors into more usable alternatives. Just recently I caught a glimpse of this: https://plus.google.com/+AddyOsmani/posts/DdWkiKsvbA2
Segmentation faults can also be very cryptic, especially in the memory related cases like you suggested, but its likely that any tool would behave in fairly unpredictable ways when it comes to any form of corruption or out of memory scenario.
Sorry again and hopefully that clarifies my thoughts.
To clarify what I was trying to convey, the issue I personally find is that JS errors often produce difficult to understand descriptions and misleading traces when compared to some alternative languages.
I do believe that there is good work being done to convert these errors into more usable alternatives. Just recently I caught a glimpse of this: https://plus.google.com/+AddyOsmani/posts/DdWkiKsvbA2
Segmentation faults can also be very cryptic, especially in the memory related cases like you suggested, but its likely that any tool would behave in fairly unpredictable ways when it comes to any form of corruption or out of memory scenario.
Sorry again and hopefully that clarifies my thoughts.
Isn't this story just about the entertainment system? I don't think anybody would advocate using node.js for avionics.
Correct, however given that any addition to the plane has the potential to cause unintended conflicts with critical systems (i.e. in the downed Swissair flight 111 example I gave in another comment) I was suggesting that these should still be treated just as seriously.
Don't get me wrong though, I don't think that using JS in a plane is a bad idea. In fact I think the aviation industry is extremely slow moving and it frustrates me, fortunately the experimental category has access to some interesting tools but for certified aircraft you're very restricted in what you can and cannot do to modify the aircraft.
Don't get me wrong though, I don't think that using JS in a plane is a bad idea. In fact I think the aviation industry is extremely slow moving and it frustrates me, fortunately the experimental category has access to some interesting tools but for certified aircraft you're very restricted in what you can and cannot do to modify the aircraft.
And 'undefined is not a function' provides a full stack trace to the line of code causing the error. In this particular example, both planes crash, so it's not like anyone would say "But at least it crashed because of a seg fault."
Get off your high horse. What a ridiculous and ignorant comment.
Get off your high horse. What a ridiculous and ignorant comment.
Yes you're right they do provide a trace, however the trace can be misleading and difficult to understand. I attempted to clarify my position in the comments above. Sorry for any offence I caused.
Did you read the article? It's about the inflight entertainment system, and has nothing to do with the flight recorders.
In flight entertainment systems have certainly been the cause of crashes in the past: https://en.wikipedia.org/wiki/Swissair_Flight_111
"the crash was generally believed to have been caused by faulty wiring in the cockpit after the entertainment system in the plane started to overheat"
It's not too far fetched to think you could end up with an infinite loop (or other random issue) in some inflight entertainment system code, causing it to overhead and potentially ignite. I'm sure there are plenty of safeguards, but they too could fail...and this is why we still have circuit breakers and a master switch in planes that a human can control. Sadly humans too can (and often do...) fail to make the right decision.
Any system other than flight surfaces, avionics and the source of propulsion to an aircraft add some degree of risk that we could otherwise fly without.
Edits: Spelling and general sillyness.
"the crash was generally believed to have been caused by faulty wiring in the cockpit after the entertainment system in the plane started to overheat"
It's not too far fetched to think you could end up with an infinite loop (or other random issue) in some inflight entertainment system code, causing it to overhead and potentially ignite. I'm sure there are plenty of safeguards, but they too could fail...and this is why we still have circuit breakers and a master switch in planes that a human can control. Sadly humans too can (and often do...) fail to make the right decision.
Any system other than flight surfaces, avionics and the source of propulsion to an aircraft add some degree of risk that we could otherwise fly without.
Edits: Spelling and general sillyness.
This seems to be a hardware issue.
People seem to be missing my point. To be clear, i'm trying to suggest that there is a high chance that the hardware fault that was triggered by overheating, was potentially caused by a software fault.
It is not good that the software malfunctioned but it should be totally isolated from rest of airplane function. Also if software could cause overheating, someone should have redesigned the hardware (heatsink/fan for example) because it was already marginal.
Yep. Likely multiple failures. The software shouldn't cause extra heat, the hardware should be able to handle it, the insulation in the plane shouldn't have caught fire, the pilot should have pulled the circuit breaker sooner...the list goes on.
Unless there's a hardware fault, no runaway loop would overheat the system so much it would ignite.
Yeah you're probably right.
Often when you review critical failures you find multiple things went wrong at once to cause the catastrophic failure. I would place a good bet that there was a failed fan, poorly secured heatsink or maybe just a clogged air filter that meant the hardware was unable to handle the additional heat being produced.
Often when you review critical failures you find multiple things went wrong at once to cause the catastrophic failure. I would place a good bet that there was a failed fan, poorly secured heatsink or maybe just a clogged air filter that meant the hardware was unable to handle the additional heat being produced.
Thus the "Fast-forward 20 years" part :-)
Yes, it's clever because it implies how entertainment slowly but inexorably manages to take insinuate itself into and corrupt every essential application.
What makes you think anyone is planning to use NodeJS in avionics in 20 years? Where have you got that information, and how is it relevant to this discussion?
Perhaps you missed the whole obvious joke thing?
What makes the joke relevant to the discussion is that this is the first thought on lots of people's mind: "gee, I hope they don't ever use it for the actual flying system".
It sure was the first thought I had, even before seeing the parent's joke.
What makes the joke relevant to the discussion is that this is the first thought on lots of people's mind: "gee, I hope they don't ever use it for the actual flying system".
It sure was the first thought I had, even before seeing the parent's joke.
>>Perhaps you missed the whole obvious joke thing?
What's remarkable about HN is that most jokes are heavily voted down with responses like "go back to reddit", and jokers regularly complain that HN has no sense of humor. And yet every now and then a joke gets voted to the top. I've yet to wrap my mind around this phenomenon, personally...
What's remarkable about HN is that most jokes are heavily voted down with responses like "go back to reddit", and jokers regularly complain that HN has no sense of humor. And yet every now and then a joke gets voted to the top. I've yet to wrap my mind around this phenomenon, personally...
I've seen the phenomenon on Reddit where two identical comments will have completely polar votes. One might have -50 and the other 50.
Someone deduced that it was the time that the comment was created that mattered. If a large number of jokesters are on at one point then their up votes will create the critical mass to push the comment to the top and keep it there.
I also believe that once a post is at the top fewer people will downvote it, either because they are afraid to go against popular opinion or merely respect it and leave it as it is.
Someone deduced that it was the time that the comment was created that mattered. If a large number of jokesters are on at one point then their up votes will create the critical mass to push the comment to the top and keep it there.
I also believe that once a post is at the top fewer people will downvote it, either because they are afraid to go against popular opinion or merely respect it and leave it as it is.
Perhaps it means that HN's cumulative sense of humor differs in some respect from your own?
I don't know whether to laugh at the suggestion that a crowd as diverse as HN has a "cumulative sense of humor" or be offended by the implied suggestion that my sense of humor matches that of Reddit's.
>I don't know whether to laugh at the suggestion that a crowd as diverse as HN has a "cumulative sense of humor"
People overestimate how different they are from the average person all the time, but regression to the mean is a thing. That's how we get a general culture (in the broad sense) -- even if there are subcultures within it.
Besides, how diverse is HN? If anything it's one of the more targeted communities -- most people here already are focused in programming and startups, and have a same-ish background even when from different countries. Contrast with something like YouTube or Reddit (general channels), where people are from all walks of life.
If 9gag, which also gets people from all around the world and with all kinds of interests and ages, can develop a "cumulative sense of humor" (and it has) then surely HN can too. This doesn't mean that everyone on HN will agree on some funny thing -- just that a large percentage will.
People overestimate how different they are from the average person all the time, but regression to the mean is a thing. That's how we get a general culture (in the broad sense) -- even if there are subcultures within it.
Besides, how diverse is HN? If anything it's one of the more targeted communities -- most people here already are focused in programming and startups, and have a same-ish background even when from different countries. Contrast with something like YouTube or Reddit (general channels), where people are from all walks of life.
If 9gag, which also gets people from all around the world and with all kinds of interests and ages, can develop a "cumulative sense of humor" (and it has) then surely HN can too. This doesn't mean that everyone on HN will agree on some funny thing -- just that a large percentage will.
> What makes the joke relevant to the discussion is that this is the first thought on lots of people's mind: "gee, I hope they don't ever use it for the actual flying system".
That's the second thought for me. The first was "thank goodness the airline I'm flying intercontinental with next week uses Boeing planes at that route".
That's the second thought for me. The first was "thank goodness the airline I'm flying intercontinental with next week uses Boeing planes at that route".
Hopefully not a 737 though, hey?
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...
[deleted]
never change, HN.
[deleted]
>and in the flight logs they can see the cause clearly
I know it's a joke, but still: the in-flight entertainment system doesn't log to the flight data recorder.
I know it's a joke, but still: the in-flight entertainment system doesn't log to the flight data recorder.
I hope they got their system thoroughly pen tested...
I bet you there are not two satellite aerials on the plane and you can bet that the important navigation systems are in some way connected to the network. Hopefully this just the aerial connected to two routers but it's probably a single router. I think I want to fly on this and start running nmap ;-) I suppose that would be considered hacking though.
I bet you there are not two satellite aerials on the plane and you can bet that the important navigation systems are in some way connected to the network. Hopefully this just the aerial connected to two routers but it's probably a single router. I think I want to fly on this and start running nmap ;-) I suppose that would be considered hacking though.
Internet access via IFE (in-flight entertainment) systems and WiFi has been a thing for a good while now. There's no new attack vector or failure mode in that respect.
There are almost certainly at least two aerials at least for the nav systems because almost every important system on an aircraft is redundant in the event one of them fails.
Interesting points:
* in-flight entertainment system devs allowed to run
open source
* system is "online" via aircrafts satellite
internet connection
* devs pushed fixes mid-flight
> (Edit: The article headline is Aircraft customer experience on a new level)
Yes, the submission title here is an example of how editorializing by picking a single detail usually ends up determining the entire discussion. We didn't change it, but probably should have.
Yes, the submission title here is an example of how editorializing by picking a single detail usually ends up determining the entire discussion. We didn't change it, but probably should have.
>devs pushed fixes mid-flight
They don't say they updated the flying server midflight, though:
"An issue was spotted mid-flight, discussed over Slack with Yle (located in Helsinki) and fixed immediately. The fix was visible whilst airborne, 10 minutes later when the latest news were updated to the aircraft."
It could well have been an issue in the infrastructure on the ground which led to garbled news. Then they pushed a fix on the ground and 10m later, the flying system got rid of the glitch. Purely to make it more dramatic, I would have been vague about that too if the fix was to the ground-based infrastructure.
They don't say they updated the flying server midflight, though:
"An issue was spotted mid-flight, discussed over Slack with Yle (located in Helsinki) and fixed immediately. The fix was visible whilst airborne, 10 minutes later when the latest news were updated to the aircraft."
It could well have been an issue in the infrastructure on the ground which led to garbled news. Then they pushed a fix on the ground and 10m later, the flying system got rid of the glitch. Purely to make it more dramatic, I would have been vague about that too if the fix was to the ground-based infrastructure.
> devs pushed fixes mid-flight
Scary, even if the entertainment system is not connected to the flight equipment.
Scary, even if the entertainment system is not connected to the flight equipment.
The article says the issue, discussed with Yle (the content provider), was fixed mid-flight - it doesn't say anything about a fix being pushed. For all with know it might not even be the code, maybe it was a property in the JSON-data of a news article that was changed from left-aligned to right-aligned?
Also - no matter if it is relevant or not in the case - being able to deploy and update fixes to a system in production without anyone noticing is a testament to good system design - and even a requirement in many cases.
Also - no matter if it is relevant or not in the case - being able to deploy and update fixes to a system in production without anyone noticing is a testament to good system design - and even a requirement in many cases.
So, it runs nodejs. Any idea on what hardware it runs on, what kind of interface(s) it has to the aircraft, what kind of OS it runs?
A little bit of Googling mentions that the Panasonic EX systems are VIA embedded x86 boards (perhaps Atom-based?) running Linux.
VIA boards typically run either ARM processor or their own (VIA) x86 compatible processors:
http://www.viatech.com/en/boards/
I run a couple of servers using VIA processors, they consume very little electricity, I run storage, web and mail servers on them. When Intel came out with the Atom, it used a little bit more electricity but was significantly more performant than the VIA. VIA has had new processors since but I don't know how they compare to the Intel low-power line.
http://www.viatech.com/en/boards/
I run a couple of servers using VIA processors, they consume very little electricity, I run storage, web and mail servers on them. When Intel came out with the Atom, it used a little bit more electricity but was significantly more performant than the VIA. VIA has had new processors since but I don't know how they compare to the Intel low-power line.
Is VIA what is left of the Cyrix/NatSemi MediaGX cores?
Yes, I think it is. The x86 version at least. They had a neat little board that I used to control a plasmacutter torch in 3 dimensions.
I had a neat little project on that setup as well. It was way too early for its audience, which is kind of a shame.
http://pics.camarades.com/v/jacques/trips/jansvisit/dscn4017...
Extremely ugly first day prototype of that plasma cutter controller, the VIA board sits in the hard drive enclosure on the right hand side, you can just about make it out.
What did you build?
Extremely ugly first day prototype of that plasma cutter controller, the VIA board sits in the hard drive enclosure on the right hand side, you can just about make it out.
What did you build?
This contraption:
https://www.youtube.com/watch?v=dAyBz8XIMsU
http://www.silverball.net/images_martin/tech_pc_case.jpg
It was a MediaGX 5520 (233Mhz) motherboard with a custom PCI board holding an array of 8mbit ROMs + flash memory and a DSP for sound playback. Douglas Comer's XINU was used as an operating system and ran from ROM.
The "too early for it's time" was less about the pinball machine and more about the MediaGX. A small Geode board + Linux could have been a really nice platform. I think a lot of ATMs are actually using this formula.
https://www.youtube.com/watch?v=dAyBz8XIMsU
http://www.silverball.net/images_martin/tech_pc_case.jpg
It was a MediaGX 5520 (233Mhz) motherboard with a custom PCI board holding an array of 8mbit ROMs + flash memory and a DSP for sound playback. Douglas Comer's XINU was used as an operating system and ran from ROM.
The "too early for it's time" was less about the pinball machine and more about the MediaGX. A small Geode board + Linux could have been a really nice platform. I think a lot of ATMs are actually using this formula.
Super nice work.
I've worked on some coin op stuff as well but more video game oriented. The original software ran on Windows, I did a linux port to show that 'it could be done' without windows. The hardest part was to switch from one game to another (multi game console) without a video mode reset.
Another application for that board is on-board computer for cars. I've got a very similar board in a nice little case that just fits under the passenger seat and wires into the car by running cables to the side of the transmission tunnel. Boot times are short (runs off a flash disk) and media are stored on a small 2.5" hard drive. I like these little systems.
I've worked on some coin op stuff as well but more video game oriented. The original software ran on Windows, I did a linux port to show that 'it could be done' without windows. The hardest part was to switch from one game to another (multi game console) without a video mode reset.
Another application for that board is on-board computer for cars. I've got a very similar board in a nice little case that just fits under the passenger seat and wires into the car by running cables to the side of the transmission tunnel. Boot times are short (runs off a flash disk) and media are stored on a small 2.5" hard drive. I like these little systems.
Just hit Ctrl C, and then type uname -a.
Anyway, I'm surprised they opted for a single threaded, non preemptive system.
Anyway, I'm surprised they opted for a single threaded, non preemptive system.
If it's completely isolated from the flight control systems then it doesn't really matter.
If the Jeep hack taught me anything, it's that some engineers have a version of "completely isolated" in mind that is not congruent with mine. I have no more faith in Airbus engineering prowess when it comes to networking than Jeep.
Cars and planes are built to very, very different standards. The avionics are separated from all systems such as the entertainment by an air gap to prevent such failures from happening.
> The avionics are separated from all systems such as the entertainment by an air gap to prevent such failures from happening.
Well, they should be, but apparently they are not:
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...
Whatever you could conclude from that article the bug bounty clause ruling those systems out would suggest they are indeed connected, as does the FBI statement (which appears to have taken a part of the conversation out of context but is in fact later on verified by the wired people as having some basis in fact, other than that the guy did not actually control the aircraft he should not have been able to get as far as he did).
I agree with you those connections really should not exist but there seem to be at least some wires bridging the air-gap, maybe read only, maybe not depending on the kind of plane.
Fortunately there appear to be enough safeguards in place to limit the damage that could be done and from what I understand these have held up. It also seems that the 'hacker' is a bit of a bragger but he got in a lot further than they initially gave him credit for, and in a way that is so simple that it makes you wonder what else they missed. The safeguards now seem to hinge on knowing what commands to issue and how to bypass authentication but that is stuff we see in an internet context on a daily basis so that seems to be - to me at least - very thin ice to skate on.
An airgap would be better and simpler.
Well, they should be, but apparently they are not:
http://www.telegraph.co.uk/news/worldnews/northamerica/usa/1...
Whatever you could conclude from that article the bug bounty clause ruling those systems out would suggest they are indeed connected, as does the FBI statement (which appears to have taken a part of the conversation out of context but is in fact later on verified by the wired people as having some basis in fact, other than that the guy did not actually control the aircraft he should not have been able to get as far as he did).
I agree with you those connections really should not exist but there seem to be at least some wires bridging the air-gap, maybe read only, maybe not depending on the kind of plane.
Fortunately there appear to be enough safeguards in place to limit the damage that could be done and from what I understand these have held up. It also seems that the 'hacker' is a bit of a bragger but he got in a lot further than they initially gave him credit for, and in a way that is so simple that it makes you wonder what else they missed. The safeguards now seem to hinge on knowing what commands to issue and how to bypass authentication but that is stuff we see in an internet context on a daily basis so that seems to be - to me at least - very thin ice to skate on.
An airgap would be better and simpler.
They generally are separated, however the 787-8 is apparently an exception, having been granted "special conditions" by the FAA in 2008. [1] The A350 has a similar design and I imagine they've also have similar special conditions, although I haven't done more than a cursory search.
[1] http://cryptome.info/faa010208.htm
[1] http://cryptome.info/faa010208.htm
That's one interesting document. I find it hard to believe these are even negotiable, and given that the trend is towards more features and connectivity between systems that does not bode well for the future. You'd think that the FAA would hold their foot down on physical separation of those systems but that does not appear to be the case, you can connect the two as long as you then put in another layer protect the domains related to information and aircraft management.
Enfin, they presumably know what they're doing, personally I'd prefer for such a bridge to simply not exist.
Enfin, they presumably know what they're doing, personally I'd prefer for such a bridge to simply not exist.
The allegations in the Telegraph article seem pretty dubious. It's based on one odd looking bloke saying he could do it. No other evidence. If it was real I presume some security guy would offer to take reports on a plane and demo it or similar but no. http://www.theguardian.com/technology/2015/may/19/hacker-chr...
They are. The guy is a poser, pure and simple. But that poser was able to access some systems by plugging in to a box under his chair that should have been tamper proof, he was able to get a lot further than he should have once he gained access to the socket underneath. And further digging revealed that there are in fact some (presumably one-way) connections between those systems and the more important bits of the aircraft. All in all, in spite of the dubious source and the questionable character of the guy that did this fairly surprising (to me).
If he had not made these stupid claims it would not have made me feel any better about all this.
If he had not made these stupid claims it would not have made me feel any better about all this.
Would this be the farthest from Earth JS has been run?
ISS has laptops. I've heard that they do everything by using Remote Desktop to a NASA box on the ground, but presumably there's some part of the client that uses a web view with some JS e.g. to show formatted text.
If the laptops run Windows between 95 and 7, then there's likely a lot of JScript and JavaScript running in things like Active Desktop, desktop widgets, possibly startup scripts and obviously inside IE. I'm not sure if all this stuff is still around in Win8+ though.
Also, please don't give them any ideas. It's enough that every other JS webdev company uses rocket-related imagery on their site, we don't want them to design actual rockets.
;).
Also, please don't give them any ideas. It's enough that every other JS webdev company uses rocket-related imagery on their site, we don't want them to design actual rockets.
;).
Most automation scripts these days tend to center around PowerShell. That said, JS is an option for integrated applications in Windows 8+, not to mention electron, nwjs, firefox/xulrunner, and the like.
JS in airflights, ok that's official now, we are doomed.
Correct me if I'm mistaken, but the avionics software would probably be written in C or Assembler.
Neither of those have SloppyDevTypeCheckComfortBlankie either, do they?
Neither of those have SloppyDevTypeCheckComfortBlankie either, do they?
Sloppy dev is a sloppy dev - whichever the language: http://www.safetyresearch.net/blog/articles/toyota-unintende...
I'm hoping for SPARK Ada or something similar: https://en.wikipedia.org/wiki/SPARK_(programming_language)
I cannot tell you how much I love SloppyDevTypeCheckComfortBlankie, how much time/money it has saved my company (converting all our JavaScript to TypeScript), and how funny it is that some people take pride in writing code that isn't typed.
I worked on IFE systems at Panasonic for several years. The so-called "head-end" (server-side) services my team worked on were written in C++ or PHP. I saw a lot PHP going on there. The server limitations weren't as strict as you would think.
The interfaces between the avionics which held actual flight data and the IFE were read-only IIRC, and otherwise fairly isolated.
The interfaces between the avionics which held actual flight data and the IFE were read-only IIRC, and otherwise fairly isolated.
JS is the new assembly, and React will be the next Visual Basic.
I'm surprised nobody mentioned the Atwood's Law yet.
I'm surprised nobody mentioned the Atwood's Law yet.
JS is a language like just about any other.. and, like VB the ubiquity of new developers starting out with it yeilds some pretty bad code. I've seen bad code in a great many languages.. and some of the worst JS code I've seen has tended come from language snobs who favor other languages, and bring in patterns that just aren't appropriate for the environment.
[deleted]
In my opinion using a language that doesn't compile into a binary with native type safety is a step backwards if it's integrated with any mission-critical system.
Love node.js and happy to see it succeed. I'm not sure if I'm a big fan of seeing it used in places where it's not, because it gives the wrong impression.
I wouldn't use node.js everywhere. I'd say python can wear more hats, but if it came down to something you can't update regularly and would cause big ramification if it'd fail. You're just making a gamble.
If you have a JS bug which wasn't caught, which could have been caught via static analysis, you're going to either go into flight with broken entertainment or wait for a mechanic to update the system.
So to reiterate. Happy for node.js, I don't think I agree with where you applied it. I hope that customers, the airline companies and node.js doesn't suffer unduly because the wrong tool was picked for the job.
Love node.js and happy to see it succeed. I'm not sure if I'm a big fan of seeing it used in places where it's not, because it gives the wrong impression.
I wouldn't use node.js everywhere. I'd say python can wear more hats, but if it came down to something you can't update regularly and would cause big ramification if it'd fail. You're just making a gamble.
If you have a JS bug which wasn't caught, which could have been caught via static analysis, you're going to either go into flight with broken entertainment or wait for a mechanic to update the system.
So to reiterate. Happy for node.js, I don't think I agree with where you applied it. I hope that customers, the airline companies and node.js doesn't suffer unduly because the wrong tool was picked for the job.
typescript?
TypeScript's safety is limited: its type annotations do not exist at runtime, so if it interacts with dynamic code, its type safety is violated.
Scalajs looks so much better.
good call on typescript. I highly recommend it.
for those who don't know, typescript gives you static typechecking and builds to JS. http://www.typescriptlang.org/
That said, node.js can be embraced by being used in places where it's strongest, like packaging web assets, front end builds, package managing js libraries, websocket stuff.
While the company selling the stuff doesn't go into much detail on how node.js is used - when bugs happen - and they will, node enthusiasts are going to get a bad rep for thinking they can use JS everywhere. Not a good idea
for those who don't know, typescript gives you static typechecking and builds to JS. http://www.typescriptlang.org/
That said, node.js can be embraced by being used in places where it's strongest, like packaging web assets, front end builds, package managing js libraries, websocket stuff.
While the company selling the stuff doesn't go into much detail on how node.js is used - when bugs happen - and they will, node enthusiasts are going to get a bad rep for thinking they can use JS everywhere. Not a good idea
What if somebody try to write 'flight control system' in node.js and 'settimeout' doesn't get fired on time !
Setting the physical safety issues aside, I cannot escape the comical image of a plane-turned-rave after the cabin mood lighting gets hacked by the bored teenager who doesn't want to read news from the airline-approved news source.
Pre-recorded safety announcements get replaced by S-Club-7 on a perpetual loop? Siren noise ever time the seatbelt sign turns on? Or how about altering the hosts file so that the official news source points to hustler,com? There is something to be said for some systems not being so heavily networked.
Pre-recorded safety announcements get replaced by S-Club-7 on a perpetual loop? Siren noise ever time the seatbelt sign turns on? Or how about altering the hosts file so that the official news source points to hustler,com? There is something to be said for some systems not being so heavily networked.
this makes the assumption that previous software was more robust at preventing this than running node.js as a backend.
It's not about the software, but the entire package. The soft/firmware can be total junk, but if it isn't networked to other systems then it isn't going to be hacked.
Take the mood lighting. Once upon a time such LEDs would be tied to a controller with three knobs, three rehostats, to set the RGB values. Done. No networking, just knobs. Hacking would require digging holes into the wall. Anyone willing to do that would just turn the knobs. But now it's connected to a tablet app. The software on that networked tablet is always, always, going to be more of a risk than the software behind those not-networked RGB knobs. It's a physicality problem.
Take the mood lighting. Once upon a time such LEDs would be tied to a controller with three knobs, three rehostats, to set the RGB values. Done. No networking, just knobs. Hacking would require digging holes into the wall. Anyone willing to do that would just turn the knobs. But now it's connected to a tablet app. The software on that networked tablet is always, always, going to be more of a risk than the software behind those not-networked RGB knobs. It's a physicality problem.
[deleted]
Shouldn't all software in a plane be written in a higher level language?
Yeah, I rolled my eyes too. That was so bad I just had to share.
Yeah, I rolled my eyes too. That was so bad I just had to share.
Node.js seems to be popular only here.
http://cbcg.net/blog/2012/02/03/if-youre-using-nodejs-youre-...
On a larger note, using JavaScript on the server-side seems kind of ridiculous. If Linden Labs came out with a server-side framework in LindenScript, would you use that? How about if Apple came out with a framework based on AppleScript?
Stopped reading right there. Well, actually, I read the next header "Callback spaghetti is about the last pattern with which you’d ever want to write anything" and realized that the author has absolutely no idea what they are talking about.
Stopped reading right there. Well, actually, I read the next header "Callback spaghetti is about the last pattern with which you’d ever want to write anything" and realized that the author has absolutely no idea what they are talking about.
> Through the WiFi, passengers will have access to an in-flight portal which serves customers content without the need to purchase an internet connection.
Isn't this just great!
/sarcasm
Isn't this just great!
/sarcasm
Node.js is running on an airplane! So frightening this is allowed! Definitely don't want to be risking my life on that plane!!
Why couldn't they use Scala instead?
Why couldn't they use Scala instead?
I'm not sure if you're being sarcastic, but this is for the entertainment system, not avionics or other mission-critical systems.
Judging by the kind of mayhem that ensues when the in-flight entertainment system breaks on an intercontinental flight you'd think some passengers would prefer it if an engine failed.
You'd hope. You'd really hope. Flight engineering is an intense, "We don't fuck around field." ... But every industry has it's "good idea at the time" and there's always a chance of these systems sharing a bus with something critical.
There's no chance these systems share a bus with something critical. Critical systems are separated by way of an air gap. There's no way they'd meet regulatory safety standards set by the FAA or EASA standards if they didn't.
You keep saying that but it has already been proven not to be the case.
Wired article related to this:
http://www.wired.com/2015/05/possible-passengers-hack-commer...
States that there is a connection but it is supposedly one-way only. So no airgap. The article then goes on to note that a 777 uses a two-way bus but requires further authentication.
Wired article related to this:
http://www.wired.com/2015/05/possible-passengers-hack-commer...
States that there is a connection but it is supposedly one-way only. So no airgap. The article then goes on to note that a 777 uses a two-way bus but requires further authentication.
You keep quoting this article, but ..
The sources are dubious (wired and telegraph). Experts quoted in the article claim its impossible, including the lead engineer of the boeing thrust management system:
> Whether it’s possible to create this condition by issuing a command from a passenger seat is a different matter, however. Soucie and others who WIRED spoke to agree with Boeing that this isn’t possible. But unlike Boeing, they provided clearer details explaining why. > >Peter Lemme, who was a lead engineer on Boeing’s thrust-management system for eight years until 1989, says the system provides the auto-throttle function that actually controls the engine thrust, and doesn’t allow the throttles for the engines to operate independently of one another.
You claim it's been "proven not to be the case". Extraordinary claims require extraordinary evidence. So far I've seen nothing from this Roberts guy. Sounds like he's just full of shit.
The sources are dubious (wired and telegraph). Experts quoted in the article claim its impossible, including the lead engineer of the boeing thrust management system:
> Whether it’s possible to create this condition by issuing a command from a passenger seat is a different matter, however. Soucie and others who WIRED spoke to agree with Boeing that this isn’t possible. But unlike Boeing, they provided clearer details explaining why. > >Peter Lemme, who was a lead engineer on Boeing’s thrust-management system for eight years until 1989, says the system provides the auto-throttle function that actually controls the engine thrust, and doesn’t allow the throttles for the engines to operate independently of one another.
You claim it's been "proven not to be the case". Extraordinary claims require extraordinary evidence. So far I've seen nothing from this Roberts guy. Sounds like he's just full of shit.
Agreed on the Roberts guy being full of shit. But there is this passage in the wired piece:
"A connection between the avionics system and the IFE does exist. But there’s a caveat.
Soucie and Lemme say the connection allows for one-way data communication only. The systems are connected through an ARINC 429 data bus that feeds information from the avionics to the IFE about the plane’s latitude, longitude and speed. The IFE uses this to populate the animated map passenger’s can use to track the plane’s movement.
“On every airplane it’s done a little differently and is done in a proprietary way,” Lemme says. But in each case, the ARINC 429 is an output-only hub that allows data to flow out from the avionics system but not back to it, he says. To talk back would require a second input bus. “I can’t think of why there would ever be an interface like this. If it’s out there, I haven’t heard of it.”
This would seem to be what Boeing was describing in its statement when it said that although inflight systems “receive position data and have communication links” to other systems on the plane, they are “isolated” from systems that perform critical functions."
So there is a link.
An airgap simply means this: the two systems are not connected. Not in any way, no physical connection exists between the two and any output from the one goes through an optical bridge into the other.
The only way air-gapped systems are possibly connected is via power rails but presumably those do not carry data nor do they have the possibility to do so.
https://en.wikipedia.org/wiki/ARINC_429
Suggests it is an electrical bus, not optically insulated.
"A connection between the avionics system and the IFE does exist. But there’s a caveat.
Soucie and Lemme say the connection allows for one-way data communication only. The systems are connected through an ARINC 429 data bus that feeds information from the avionics to the IFE about the plane’s latitude, longitude and speed. The IFE uses this to populate the animated map passenger’s can use to track the plane’s movement.
“On every airplane it’s done a little differently and is done in a proprietary way,” Lemme says. But in each case, the ARINC 429 is an output-only hub that allows data to flow out from the avionics system but not back to it, he says. To talk back would require a second input bus. “I can’t think of why there would ever be an interface like this. If it’s out there, I haven’t heard of it.”
This would seem to be what Boeing was describing in its statement when it said that although inflight systems “receive position data and have communication links” to other systems on the plane, they are “isolated” from systems that perform critical functions."
So there is a link.
An airgap simply means this: the two systems are not connected. Not in any way, no physical connection exists between the two and any output from the one goes through an optical bridge into the other.
The only way air-gapped systems are possibly connected is via power rails but presumably those do not carry data nor do they have the possibility to do so.
https://en.wikipedia.org/wiki/ARINC_429
Suggests it is an electrical bus, not optically insulated.
If there existed any possibility of an influence of the entertainment system over the controls of that model of plane, an EAD would have been published by now. EADs are public: http://www.faa.gov/aircraft/air_cert/continued_operation/ad/... . Where is the EAD that signals what would be a design failure of the highest level and grounds that model of aircraft until the design has been revised?
If it was not extremely obvious that such an influence cannot exist with the law of physics that we understand, an investigation would be ongoing. The word “investigation” does not appear in the WIRED article, and “investigators” in the Telegraph article only refers to FBI.
The FBI is not qualified to tell whether an aircraft is so obviously immune to the defects that Roberts claim to have exploited that the investigation is an open-and-shut case. They don't like it when people plug into things they aren't supposed to plug into, and this is what they are accusing him of.
If it was not extremely obvious that such an influence cannot exist with the law of physics that we understand, an investigation would be ongoing. The word “investigation” does not appear in the WIRED article, and “investigators” in the Telegraph article only refers to FBI.
The FBI is not qualified to tell whether an aircraft is so obviously immune to the defects that Roberts claim to have exploited that the investigation is an open-and-shut case. They don't like it when people plug into things they aren't supposed to plug into, and this is what they are accusing him of.
Agreed that there likely was no risk. I'm just very much surprised that the two systems are connected in any way shape or form at all, I'd have expected a much more rigorous segmentation (as in: no connection at all between the two systems, including the 'flight information display').
Call me paranoid.
That this guy was able to access the system at all is already quite a surprise.
Call me paranoid.
That this guy was able to access the system at all is already quite a surprise.
You keep using that word... I don't think it means what you think.
JavaScripts on a Plane?
For those missing the reference: https://www.youtube.com/watch?v=vkckhcqiwM8
* What makes nodejs running on an entertainment system dangerous?
* Outside of bias, how strong of a case is there to use another language?
* why shouldn't we use high level languages, even for avionics? Obviously not JS because numbers aren't transitive and it just isn't the usecase, but we don't need to optimize for 1kb of memory anymore. C family languages are the backbone of many things and that makes sense but do we need to keep using java and C-like languages or could we use python or something of similar nature where memory isn't manually allocated.