I'm working on a project which is currently planned to use an ARM Cortex M3 from ST (device is from the STM32L151xC series). I've never used the Cortex chips before and my ARM experience is quite limited too, is anyone here prepared to give me the executive precis of the state of the compiler/debugger situation for these chips ?
If I'd been asked the same question 10 years ago about the 8051 I'd have said Keil compilers + Hitex emulators, and that is the kind of level of reply I'm looking for. Of course a more detailed response would be appreciated too ;-)
Also, what is the panel's thoughts on RTOS for these small devices ? I see Safe/OpenRTOS is available but RTEMS also supports the ARM Thumb instruction set since the version before the current one, is there a generally preferred RTOS for the M3 architecture ? Requirements are a small/cut down tcp stack but ony if it's easier then rolling my own to suite very limited requirements.
I've been happy with Rowley's CrossWorks for general CM3 and STM32 development. They do include an RTOS as part of the package. No network stack, as yet, but they do say they're working on one.
I can recommend the Keil/ARM C compiler but I have serious reservations about their "middleware" (file and network support). Keil/ARM support is not as good as it was but I don't know how it compares with IAR or Rowley.
ARM have announced a standard RTOS API and their own simple RTOS is available FOC which complies. I expect Rowley and IAR will support it but you should check.
formatting link
If I were starting from nothing now I would look very carefully at Keil, IAR and Rowley. My experience of network stacks is that none of them work properly (ie comply with RFCs and don't fall over) in the price range free -> £5000 (I haven't tested them all !!!) so my advice is go for open source/liberal license and expect to have to work on it.
Choice of toolchain depends a *lot* on your budget and level of comfort/confidence with the parts/technology/etc. If you feel you'll need a bit more hand-holding, then spend the money on one of the better supported (i.e., "more responsive") vendors' products. If you've been around the block a few times (other devices, etc.) the "free" solution may be more to your liking.
First, do you really need an RTOS? Or, is an MTOS acceptable? What sorts of services do you expect from the OS? Is your design relatively static (a fixed set of tasks that run in perpetuity)? Or, does it's duties vary more dynamically?
I don't think the parts you cited have "ethernet" hardware -- or, are you planning on adding this externally?
Do you really need TCP or is UDP adequate? How friendly/adversarial is the environment in which you must operate? How much of a honey-pot do you represent?
There are a couple of trimmed back, "public" stacks out there that don't require too much work to port. But, they make assumptions about how they will shoehorn into your system (so you need to understand if you can tolerate their requirements).
Depending on how much/little you require from the stack, you might find it easier to write those portions that you will need. Comer has some good texts for The Basics of a simple stack. Stevens if you're looking for the GrownUp course...
(Either/both would be good reads to consider the issues that each aspect of the stack addresses -- and, by extension, how "your"/any implementation can be vulnerable to exploits)
Yes, one of these days. ;-) I try to stick to a minimalist network implementation with just ARP and UDP and eschew all of the folderol with a compliant TCP stack. That's assuming that a CANbus solution can't be made to work ...
Yup. Going to TCP adds *lots* of complexity (which also adds lots of *exploits*!).
Biggest problem (IM) with network stacks in an embedded system is remembering they were designed for *benign* environments. I.e., they try to handle the consequences of (unfortunate) hardware and transient faults -- not deliberate attacks!
Since embedded systems are more likely to "do things" (rather than just move bytes of data around), the consequences of that sort of intentional abuse can be significant (botching a production run; forcing mechanisms to do things when/how they shouldn't; repricing items; etc.)
Note that UDP doesn't automatically immunize you from these sorts of exploits. All exploits attack assumptions. So, just sticking with UDP still leaves you making *some* assumptions. And, if you're using UDP to avoid the *resources* associated with TCP, then it's likely you've made lots of assumptions there, as well.
Finally, if you have to "play nice with others", then you are far more UNconstrained than if you have explicit knowledge of the other partners with which you will be communicating. I.e., if I can control (design) both ends of the link, then each end can *know* what to expect from the other and can be more vigilant against attacks ("Gee, that guy shouldn't be trying to ping me -- at least, not *now*! And how did his MAC address 'suddenly' change? THAT's not supposed to happen...")
[A general purpose, compliant stack for use in an unspecified application domain is a tall order -- especially if you are conscious of resource requirements!]
Yup. Significantly "safer" (but really only security by obscurity)
Maybe I should be looking harder at those nice Wiznet chips I used to use. Put all your TCP/UDP/IP worries at the other end of an SPI connection -- and an interrupt. I suppose there's a chance for trouble via the interrupt.
I don't think they buy you much by way of "protection" against adversaries.
Consider: protocols that sit *atop* these still require *your* code to safeguard itself against protocol exploits. E.g., if you run something atop UDP, even if the chip provides you legitimate UDP packets, your code still has to implement the protocol that *uses* UDP (e.g., DNS). Any oversights in your code leave you just as vulnerable as if you had implemented the entire stack yourself (on bare iron).
And, *within* those protocols handled by the chips (e.g., TCP), you have to hope they have covered all the bases regarding potential exploits at those lower levels (e.g., SYN flood).
[I don't recall ever seeing enough details about their implemetation to know *which* attacks they've already taken into consideration.]
I think you have to evaluate the needs of your product and application to determine what the *real* vulnerabilities and exploits are likely to be. It's too easy to rationalize that "no one is going to BOTHER hacking this device". Then, you later discover that you've internalized this belief so completely that you now treat it AS IF it was "unhackable" (which is NOT what you originally rationalized) and start layering other things atop it. And, one of *those* things becomes a honey-pot for an attacker -- while you've lulled yourself into thinking everything is safe/secure.
I.e., the assumptions you set in place initially are no longer appropriate as things evolve.
When I was in school, we used to hack pinball machines. Not to "make money" but, rather, to play for free (and make *some* nominal amount of money in the process).
We did this by exploiting assumptions and faults in their implementations. Things that the designers didn't consider as vulnerabilities.
They would focus on keeping the cashbox "secure" -- prevent people from stealing *money* from the machine. But, if you manage to get "free play" from the machine, isn't that just as bad for the owner/operator? His maintenance costs are proportional to *play*, not *pay*. So, if you can play
100 games for $0.01 (total), this doesn't bode well for him!
Especially when you are doing this every day... :)
Linux makes sense in a growing number of scenarios, even in the (32-bit, virtual memory) embedded market : connected TVs, "smart" phones, decoder set-top boxes, routers, etc. The TCP/IP stack in Linux is robust and mature, and the rare security bugs are fixed fast.
Linux, FreeBSD and OpenBSD TCP stacks were designed to withstand active and focused attackers.
lwip is very modular. One can disable TCP, and keep only DHCP, ARP and UDP, for example.
For even smaller systems, there used to be uip (from which lwip emerged, if I got the history right) but it seems to have been merged within a larger project.
And you will notice that desktop stacks take a *boatload* of resources! Have you tried porting one to an environment with (just) 10's or 100's of KB of total RAM? You're looking at 10-20KLoC just for the network stack *not* counting any protocols/services layered on top of that!
Just because a bug is fixed in a Linux/*BSD release (or patch), doesn't automatically convey those same fixes to the TV/phone/STB!
Also, the nature of attacks on a desktop/server is different than from an embedded device. The desktop stack just has to safeguard against being *crashed*. Does it report to the userland that it is effectively disabled due to an ongoing DoS attack? Or, do each of the application tasks have to *deduce* this by noticing that (all of) their TCP timers are expiring? Does the stack tell its clients which connections appear to be under attack? Or, does each client application just see a reduced effective bandwidth? (how do they even know it is "reduced"??)
[consequences of layering]
The desktop stacks tend to be heavily layered. Resources are (and remain) committed for longer than necessary in a *specific* application domain.
E.g., I do a *lot* of processing in and just above the network driver (i.e., low in the stack) so I can discard "inappropriate" incoming packets before they percolate up the stack (to the appropriate level of abstraction where they might, otherwise, be recognized as "inappropriate"). Outgoing traffic inherits the priorities of the sending task, etc. I.e., the stack is more of an extension of the application than a separate "service" provided to it.
In a desktop stack, you either rely on hardware MMU/VM mechanisms to move data between userland and the kernel or do lots of copyin/out's. The stack has no idea how it is being used/abused so has to take a generic approach to how it provides its services (to the application).
There are costs (time+space) for this generality. In a desktop, you usually have (or can upgrade to have) these resources. How much "slop" (extra cost) do you add to your embedded device to safeguard against this *possibility* (which may never come to pass)?
Desktop stacks tend to be more focused on throughput at the expense of all else. Embedded systems tend to be more concerned with a particular "functionality" within a given resource set.
Desktops are often overkill for *specific* markets/applications. If you look carefully at your application and what it expects of its environment, you can find many opportunities where a "general purpose" network stack can be trimmed down to better fit that application -- saving resources, improving resiliency and "predictability" in the process.
This sort of scrutiny is, IMO, invaluable in designing robust products; how can you be comfortable with an implementation if you don't understand the technology on which it relies (to a level of detail that allows you to excise those portions that are inappropriate, liabilities, etc.)?
Oh, really? We have clients with instruments on a raw internet feed - no firewall, nothing. The instruments were attacked within 30 seconds of first power up.
Now our stack survives this environment. But then, we charge for our stack.
formatting link
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
There is also the point that in many cases, you /have/ a benign environment. It is very common for the network of embedded systems to be a closed network - you know exactly what is connected to the network, and what software is running on the systems. If you need to connect to a dangerous network (such as the Internet), you put appropriate firewalls in between.
It is all about designing the system appropriately, and putting the right kind of resources in the right place. If you need to connect to dangerous networks, then you need a stack that is tried and tested against such environments. But if you only need to connect to safe, known networks, then it's fine that your stack goes offline (denial of service) at the first attack, and that you control it by unencrypted telnet connections and pass around passwords using plain text.
The danger, of course, is when people use software and configurations targeted at benign networks, and then connect them to dangerous ones. But that's the fault of the system designers or users, not of the stacks.
That sounds useful but is there any way to find out how much each component costs in terms of RAM & ROM space ? I don't know yet what I'm going to need but I do know I have to http post to a server via a GSM modem and there may be a spot of browsing to do as part of that.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.