Hackers can take over any Chrysler vehicle from the last 2 years. Yes, fully remotely. Yes, including steering, brakes and transmision.
-
For that matter, why are things like transmission and brakes connected to a network in the first place, let along one with access to the Internet?
Because with just a firmware upgrade and some other tweaks, you'll have self-driving cars!
-
putting words in my mouth
People who do embedded programming are just too stupid.
<e
-
Ada?
I was thinking that Forth might be a better choice. It's a totally different approach (you'd better love that RPN!) but it scales down to minuscule hardware very nicely.
-
I think this is the point where regulations actually have a place.
Yes, we can wait until the "market fixeth all" - but until that point, given the horrible track record of certain companies, we'll have to contend with a slew of insecure cars (which naturally won't magically vanish from the streets even after they got their shit together).
-
@lesniakbj said:
Now, answer my question. How can I build embedded systems in anything other than a low level language?
#YOU FIND A FUCKING WAY
Why am I repeating myself?
Is there a high-level, GC language that allows you to write to a hardware register located at address 0x00010874? I don't know of one. AFAIK, any Java, C# or whatever program that needs to access has to call a library routine written in a lower-level language (C, C++, ASM) to do that for them, but that is exactly what any embedded program needs to do.
Maybe in Blakeyland, where car electronics are built around PC-type microprocessors, the engine control, entertainment and whatever software can be written in C#, but there is still going to have to be code that talks to the actual hardware, and that, at least, is still going in a language that can access arbitrary, non-virtual, non-managed addresses. Maybe there's a better way to do that than writing
*((uint32_t*) 0x00010874 |= 0x00000001;, but ultimately that's what an embedded programming language needs to be able to do.
-
This inflexibility of thought really bugs the shit out of me.
-
I agree. Enough about you though, what's your response to the topic at hand?
-
I think this is a case of "If all you have is a hammer, everything looks like a nail."
-
This inflexibility of thought really bugs the shit out of me.
How can thought be inflexible? THOUGHTS CAN'T BE BENT
-
This inflexibility of thought really bugs the shit out of me.
Ok, how would you do this in a language of your choice. I'll make it simple:
The entertainment unit has a software volume control. It's an 8-bit register — 256 volume levels (in reality, probably only maybe 5 or 6 bits would be used; you don't really need that fine control of audio volume, but whatever). You can have whatever sort of abstraction you want in the software, but eventually it has to control the real, hardware audio amplifier. The gain of the audio amplifier is set by a DAC, where the D comes from the 8-bit register. The value in those 8 flip-flops is connected to the DAC. The value of those 8 flip-flops can set by writing to a specific MMIO address. That address can be abstracted to a program variable, but reading or writing that variable must somehow result in reading or writing that specific hardware address. It can't be allocated or deallocated, GC'd, managed, or even cached. Every use of the variable must touch the actual hardware.
Ready, begin. Show your work.
-
The thread is about Chryslers. Not about "embedded apps in general". If you move your dumb little eyeballs to the top of the screen, the topic's written right there for your perusement pleasure.
If you don't broaden the discussion from Chryslers to embedded apps in general, that leaves people to come up with ad hoc solutions willy-nilly. Chrysler's gonna wind up with Ada, Ford'll be using Haskell, GMC will stick with C, and so on. Who cares, tho, that we've re-created the wild west, because @blakeyrat's one specific problem today has been solved, no matter how many new ones it creates tomorrow!
-
The problem here is not that we have small microcontroller-like chips that are programmed in ASM/C/whatever and touch the hardware -- those weren't "hacked" (those are likely tested under conditions where switching to a higher level language wouldn't help(*)). What was hacked was the "big" on-board computer that's runs the entertainment/multimedia system and that's connected to the outside world in various ways. That system likely already runs on hardware similar to a smartphone (and, could already be running some higher-level language that's more protected, after all that code is not exactly critical).
The problem is really that this big computer, which can talk to the internet, also talks directly to all the other components. There's no reason for the entertainment system to ever be able to tell any other system on the car to accelerate/brake/whatever. Period.
(*) For instance, some of this HW+SW is tested under conditions where errors are injected by e.g., randomly flipping bits in the registers/memory, and the system is still expected to work/recover.
-
How can thought be inflexible? THOUGHTS CAN'T BE BENT
Meanwhile, blakey's ideas results in the story of Bob and the Java-powered toaster that toasts bread using waste CPU heat.
-
Java-powered
I mean, it is pretty hot... Not sure how efficient it is to run on coffee, but... meh...
-
The problem is really that this big computer, which can talk to the internet, also talks directly to all the other components. There's no reason for the entertainment system to ever be able to tell any other system on the car to accelerate/brake/whatever. Period.
You probably missed the part where the CAN bus does not have the capability and won't ever be capable of preventing something like that. As soon as something is connected to the CAN bus it can practically send any kind of data anywhere.
-
The reason why I said "not C" is because C is, well, pretty shitty when it comes to avoiding bugs.
C was designed to be very low level, and sacrifice everything for efficiency and memory usage (this was back in 1970, remember?). It has no bounds or overflow checking, you have to store the size of every array separately, pointer arithmetic is often required, etc.
What better choice is there? I don't know. But surely there must be something better. It doesn't have to require a runtime, it could be a fully compiled language designed for safety (so only marginally less efficient than C). You could even take a subset of C and modify it for the task.
And if that's still not enough, you have a choice:
- Upgrade your hardware so you can use a higher level language (just watch out for bugs in the runtime code).
- Simply code slower and be more careful.
-
Well, IMO a solution would be to not have that part connected to the CAN bus directly. Rather make it talk to some secondary device that acts as a "firewall" of sorts. (Yeah, that'll increase costs a bit, but not having your cars remote controlled by hackers seems like a worthwhile feature... maybe they can sell it as a premium option.)
-
that'll increase costs a bit
Oh noes! We're adding a few cents to the production cost of a consumer product that will retail for many thousands of dollars! Where will our profits come from now?!
-
Ok, how would you do this in a language of your choice. I'll make it simple:
The entertainment unit has a software volume control. It's an 8-bit register — 256 volume levels (in reality, probably only maybe 5 or 6 bits would be used; you don't really need that fine control of audio volume, but whatever). You can have whatever sort of abstraction you want in the software, but eventually it has to control the real, hardware audio amplifier. [etc]
So you add an instruction to your high-level language that writes to a hardware register.
Was all that text just to ask for this?
You probably missed the part where the CAN bus does not have the capability and won't ever be capable of preventing something like that. As soon as something is connected to the CAN bus it can practically send any kind of data anywhere.
That doesn't seem like an unsolvable problem either. For example, you could split the CAN bus in two networks and join them through a simple microprocessor that retransmits messages from one side to the other (but not the other way around). Or build an authentication protocol on top of CAN. Or ditch CAN and use something where you can tell where the packets come from.
-
That doesn't seem like an unsolvable problem either.
It's easy to solve; what do you think mobile phones do? The baseband processor is quite thoroughly off limits when it comes to the apps, and is responsible for accessing the regulated network correctly. Switching to talking to CAN bus instead is not a major architectural difference in terms of how you handle system security.
-
As far as having the entertainment center display diagnostics...
The idea of having thing A query thing B for data without allowing an attacker to compromise thing B somehow seems familiar but.... hm.... where have I heard of that problem before.... hm.... nope, not coming to mind.
-
So you're saying we should put a web server in the engine?
-
yup,
apache has mod_diesel_engine
just make sure to run debian stable, and you're set
-
Do you realize just how much more a big, fat SOC costs in hardware NRE?
A fucking pi is plenty powerful. And 25$ retail...
Linux is a fine rtos, limit the attack surface by limiting the interface ( physically if needed) the os should only ever Marshall messages.
-
It's easy to solve;
Right.
I've got this nice castle in the Carpathian Mountains. Interested? It's cheap.
-
Linux is a fine rtos, limit the attack surface by limiting the interface ( physically if needed) the os should only ever Marshall messages.
Yes, because that's how we secure the Internet - by limiting which clients can talk to our web servers.
CANbus is a networking protocol that allows devices to communicate. It's not the networking layer's responsibility to implement security. Please don't attempt to secure stuff by breaking the network. The equivalent of a firewall is prudent, but it won't help against most threats.
It's possible to fix this problem. None of the fundamental technologies need to be changed, just the implementation details. Chrysler got themselves here by being lazy and negligent. That is the only thing that needs to be fixed.
-
Yes, because that's how we secure the Internet - by limiting which clients can talk to our web servers.
Strangely enough, this approach works quite well for airplanes. It may not have been intended as a security feature in addition to making the whole thing reliable, but, hey.
Now, how many planes have been hacked as of yet? And in contrast, how many web servers?
-
secure the Internet
We're securing a fucking car here. I was thinking internally. The remotely available controller (External) should be air gapped from vital components. It should be able to issue a limited set of commands to an (internal) controller, and read some data.
The car/internal controller should never accept nonsense commands from the external interface (say disabling the brakes while driving).
A simple state machine would do as an interface - the external box could be a pi.Strangely enough, this approach works quite well for airplanes. It may not have been intended as a security feature in addition to making the whole thing reliable, but, hey.
Didn't we have someone school us on airplane security ? Was that you ? Because i somewhat liked that model, even if not perfect.
-
I've got this nice castle in the Carpathian Mountains. Interested? It's cheap.
I'll swap you for this nice bridge I've got lying around…
-
I was thinking that Forth might be a better choice. It's a totally different approach (you'd better love that RPN!) but it scales down to minuscule hardware very nicely.
Forth does scale down quite well -- but it'd be rejected by the Blakeyrats of the world for the same reason C is.
Is there a high-level, GC language that allows you to write to a hardware register located at address 0x00010874? I don't know of one. AFAIK, any Java, C# or whatever program that needs to access has to call a library routine written in a lower-level language (C, C++, ASM) to do that for them, but that is exactly what any embedded program needs to do.
Maybe in Blakeyland, where car electronics are built around PC-type microprocessors, the engine control, entertainment and whatever software can be written in C#, but there is still going to have to be code that talks to the actual hardware, and that, at least, is still going in a language that can access arbitrary, non-virtual, non-managed addresses. Maybe there's a better way to do that than writing
*((uint32_t*) 0x00010874 |= 0x00000001;, but ultimately that's what an embedded programming language needs to be able to do.
QFT! At the end of the day, embedded code has to touch hardware, and it cannot guarantee that that hardware follows the "standard patterns" established in the PC world -- some of it does, some of it has its own patterns, and there's always that one device out there that speaks some just-incompatible-enough bastard offshoot protocol or worse yet, a totally custom protocol.The entertainment unit has a software volume control. It's an 8-bit register — 256 volume levels (in reality, probably only maybe 5 or 6 bits would be used; you don't really need that fine control of audio volume, but whatever). You can have whatever sort of abstraction you want in the software, but eventually it has to control the real, hardware audio amplifier. The gain of the audio amplifier is set by a DAC, where the D comes from the 8-bit register. The value in those 8 flip-flops is connected to the DAC. The value of those 8 flip-flops can set by writing to a specific MMIO address. That address can be abstracted to a program variable, but reading or writing that variable must somehow result in reading or writing that specific hardware address. It can't be allocated or deallocated, GC'd, managed, or even cached. Every use of the variable must touch the actual hardware.
Ready, begin. Show your work.
+0xFFThe problem here is not that we have small microcontroller-like chips that are programmed in ASM/C/whatever and touch the hardware -- those weren't "hacked" (those are likely tested under conditions where switching to a higher level language wouldn't help(*)). What was hacked was the "big" on-board computer that's runs the entertainment/multimedia system and that's connected to the outside world in various ways. That system likely already runs on hardware similar to a smartphone (and, could already be running some higher-level language that's more protected, after all that code is not exactly critical).
Yeah, and I mentioned earlier that the problem at the systems-design level is that CAN is simply not designed to isolate devices from each other:You probably missed the part where the CAN bus does not have the capability and won't ever be capable of preventing something like that. As soon as something is connected to the CAN bus it can practically send any kind of data anywhere.
Yep. They'd have to change to a different protocol altogether, which'd cause major upheaval in several places, including third-party/subcontracted/shared parts and diagnostic tools; or segment the bus with a security barrier device as you point out:
Well, IMO a solution would be to not have that part connected to the CAN bus directly. Rather make it talk to some secondary device that acts as a "firewall" of sorts. (Yeah, that'll increase costs a bit, but not having your cars remote controlled by hackers seems like a worthwhile feature... maybe they can sell it as a premium option.)
It's easy to solve; what do you think mobile phones do? The baseband processor is quite thoroughly off limits when it comes to the apps, and is responsible for accessing the regulated network correctly. Switching to talking to CAN bus instead is not a major architectural difference in terms of how you handle system security.
Yep -- the baseband is a total black box (which makes designing a truly secure mobile phone interesting, as you wind up having to treat the baseband as a hostile entity ;) )A fucking pi is plenty powerful. And 25$ retail...Linux is a fine rtos, limit the attack surface by limiting the interface ( physically if needed) the os should only ever Marshall messages.
I said NRE -- non-recurring engineering -- the Pi's board requires fine-pitch PCB processing and BGA assembly (if not POP), and will likely not survive well in @abarker's engine compartment, trashing his AM radio reception in the process of dying of heatstroke. Getting an ARM SoC board that can do that at automotive-grade quality and reliability levels isn't impossible -- its just a giant pain in the rump compared to doing the same thing with a smaller microcontroller that's more likely to be available in a high-reliability/extended-temp version, much kinder to lay out for, and much smaller of a font of EMI.
-
Please, tell me how I can do systems/embedded programming in anything other than C, C++, or ASM.
Rust. D. SML. O'Caml. Haskell. Ada. Modula-#. We have these fancy things called "compilers" that turn one language into another. Since you know C and C++, possibly you've heard of them.OK, less snarkily (and assholey), there's no reason why 99% of code running on even an embedded system needs to be written in C/C++/ASM, except perhaps for computing power issues (in which case spend the $2 to double your power). Singularity is an OS written in C#. Compilers and runtimes can be self-hosting. This is a solved problem.
-
Seen the video yesterday. Nervous driver being nervous because he was being hacked while on a highway which could be real dangerous... Well why did you explicitly decide to try and get hacked while at the highway, as you said a few scenes before? Funny. Anyway...
If you design a car's entertainment system with the proper methodology, in a language and environment focused on security (i.e. not C)
i'd say a sufficient "good start" would be to stop using embedded linux, which it surely does.
-
Forth does scale down quite well -- but it'd be rejected by the Blakeyrats of the world for the same reason C is.
They can stick to programming the entertainment system.
-
I don't give a shit how it's done.
But the best way to fix brain-dead bullshit like this is to
wave your hands in the air like you don't care?
-
Bob and the Java-powered toaster that toasts bread using waste CPU heat
Olympic Cyclist Vs. Toaster: Can He Power It? – 03:14
— The Toaster Challenge
-
and will likely not survive well in @abarker's engine compartment, trashing his AM radio reception in the process of dying of heatstroke
Listen, the solution I'm proposing need not change anything currently in the car, only changing the external connections. Instead of the current connection to the Internet/radio/Bluetooth etc. You place a simple interface that's very limited, and an external fast computer like the pi.
-
That was mean. They could at least have put a slice in each slot.
-
I think this is the point where regulations actually have a place.
Yes, we can wait until the "market fixeth all" - but until that point, given the horrible track record of certain companies, we'll have to contend with a slew of insecure cars (which naturally won't magically vanish from the streets even after they got their shit together).
The NHTSA would like to have a word with you, e.g. "WTF do you think we're doing, playing checkers?"
Chrysler's gonna wind up with Ada, Ford'll be using Haskell, GMC will stick with C, and so on.
Lies. No one writes production code in Ada or Haskell.
-
Rust. D. SML. O'Caml. Haskell. Ada. Modula-#. We have these fancy things called "compilers" that turn one language into another. Since you know C and C++, possibly you've heard of them.
I give you Rust and Ada, as they seem to be able to handle systems programming.
Haskell, I bet could do it, but that would be a nightmare (looking it up... yes, its a nightmare)...
As for the others, I don't know enough about them, so let's all say they would be fine choices as well!
OK, less snarkily (and assholey), there's no reason why 99% of code running on even an embedded system needs to be written in C/C++/ASM, except perhaps for computing power issues (in which case spend the $2 to double your power). Singularity is an OS written in C#. Compilers and runtimes can be self-hosting. This is a solved problem.
Power consumption and resource constraints really, that and you can't actually abstract the true hardware calls; they need to be done by a language that directly interfaces with the hardware. Creating interpreters or compilers won't necessarily work unless they are 100% aware of the hardware conditions. We may have the capability to run an OS in C# or Java, but in the end it's just not practical. We don't want OS's and hosted code on embedded systems. We need quick, performant code.
-
Haskell, I bet could do it, but that would be a nightmare (looking it up... yes, its a nightmare)...
I actually did look it up, and there's literally a company that writes controller software that runs on trucks in Haskell.We need quick, performant code.
I will take "won't kill me" over "quick and performant", but maybe that's just me.
-
I give you Rust and Ada, as they seem to be able to handle systems programming.
Rust seems to be specifically-designed to write low-level code like this while also removing possibilities for vulnerabilities.
Switching to Rust would be a great idea for this industry, IMO.
-
I will take "won't kill me" over "quick and performant", but maybe that's just me.
Quick and performant (meaning complies to specifications) code in time critical environments will save your life while we wait for that "safe" code to finish executing.
I actually did look it up, and there's literally a company that writes controller software that runs on trucks in Haskell.
This scares me a lot. Remind me never to think of working there. Or think of them period. Or mention Haskell.
Rust seems to be specifically-designed to write low-level code like this while also removing possibilities for vulnerabilities.
Switching to Rust would be a great idea for this industry, IMO.
I don't disagree with this. Rust is pretty nice, though not completely shoot yourself in the foot proof.
-
The NHTSA would like to have a word with you, e.g. "WTF do you think we're doing, playing checkers?"
Well, considering their track record for electronic security in cars, that may very well be the case.
-
Well, considering their track record for electronic security in cars, that may very well be the case.
What is the track record? It all seems pretty recent. This is the first actual scary thing I've noticed.
-
The track record is: "We'll wait until after there is a real problem even when you can see the problems coming from a mile away."
And there have been other reports of similar stunts two years ago.
Hackers Reveal Nasty New Car Attacks--With Me Behind The Wheel (Video)
A pair of Pentagon-funded hackers prove it's possible to take control of your car with a few keystrokes. Time for Detroit to wake up.
Granted, those guys still needed physical access but even then you could see the writing on the wall:
But Miller and Valasek’s work assumed physical access to the cars’ computers for a reason: Gaining wireless access to a car’s network is old news.
edit: Hell, there's even a report from five years ago:
Automobile computer systems successfully hacked
The alarming number of safety recalls appearing in headlines of late is worrying enough. Now researchers have shown that it's possible to take away driver control of a moving vehicle by remotely hacking into relatively insecure computer systems common in modern automobiles. The team managed to...
-
edit: Hell, there's even a report from five years ago:
And how much actual trouble has it caused so far? I'm not trying to apologize for lack of security, but you're talking like it's causing injuries or deaths already. Seems like there are probably a zillion easier ways to do this sort of thing, assuming someone actually wanted to in the first place.
An unsecured server that stores credit card numbers has an obvious value. This sounds like possibly an exotic way to commit a murder. Would make for good TV.
-
This sounds like possibly an exotic way to commit a murder. Would make for good TV.
+1 Would watch. Zoom. Enhance.
-
Yeah, sure. There are zero nutjobs around who would love to exploit something like this.
Considering that you'd only need to be in the neighbourhood and would leave zero trace that you were the one exploiting something like this, it's not exactly an "exotic" way to commit murder and/or general mayhem.
-
This goes in the same fear bucket as "cancel all the sporting events because someone could bomb them".
-
This goes in the same fear bucket as "cancel all the sporting events because someone could bomb them".
If you say so. I'd rather not have my car being remotely exploitable.
