Forums

ARM Cortex M3 newbie questions

Started by Boo May 4, 2012
Hi Rich,

On 5/6/2012 10:02 AM, Rich Webb wrote:
> On Sun, 06 May 2012 16:17:10 +0200, Noob<root@localhost> wrote: > >> Rich Webb wrote: >> >>> 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. >> >> lwip is a nice open-source network stack. >> http://savannah.nongnu.org/projects/lwip/ > > 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.
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!]
> That's assuming that a CANbus solution can't be > made to work ...
Yup. Significantly "safer" (but really only security by obscurity)
Don Y wrote:

> On 5/6/2012 10:02 AM, Rich Webb wrote: >> On Sun, 06 May 2012 16:17:10 +0200, Noob<root@localhost> wrote:
> [A general purpose, compliant stack for use in an unspecified > application domain is a tall order -- especially if you are > conscious of resource requirements!] > >> That's assuming that a CANbus solution can't be >> made to work ... > > 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. Mel.
Hi Mel,

On 5/6/2012 1:57 PM, mwilson@the-wire.com wrote:
> Don Y wrote: > >> On 5/6/2012 10:02 AM, Rich Webb wrote: >>> On Sun, 06 May 2012 16:17:10 +0200, Noob<root@localhost> wrote: > >> [A general purpose, compliant stack for use in an unspecified >> application domain is a tall order -- especially if you are >> conscious of resource requirements!] >> >>> That's assuming that a CANbus solution can't be >>> made to work ... >> >> 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... :)
Don Y wrote:

> Yup. Going to TCP adds *lots* of complexity (which also adds > lots of *exploits*!).
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.
> 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!
Linux, FreeBSD and OpenBSD TCP stacks were designed to withstand active and focused attackers.
> 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.)
cf. for example http://www.infoworld.com/d/security/spoiler-alert-your-tv-will-be-hacked-191013 Regards.
Rich Webb wrote:

> On Sun, 06 May 2012 16:17:10 +0200, Noob <root@localhost> wrote: > >> Rich Webb wrote: >> >>> 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. >> >> lwip is a nice open-source network stack. >> http://savannah.nongnu.org/projects/lwip/ > > 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.
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. Regards.
On 5/7/2012 12:51 AM, Noob wrote:
> Don Y wrote: > >> Yup. Going to TCP adds *lots* of complexity (which also adds >> lots of *exploits*!). > > 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.
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!
> The TCP/IP stack in Linux is robust and mature, and the rare > security bugs are fixed fast.
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]
>> 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! > > Linux, FreeBSD and OpenBSD TCP stacks were designed to withstand > active and focused attackers.
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.)?
>> 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.) > > cf. for example > http://www.infoworld.com/d/security/spoiler-alert-your-tv-will-be-hacked-191013 > > Regards.
On Sun, 06 May 2012 11:35:30 -0700, Don Y <not@my.name> wrote:

>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!
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. http://www.mpeforth.com/powernet.htm 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
On 07/05/2012 15:27, Stephen Pelc wrote:
> On Sun, 06 May 2012 11:35:30 -0700, Don Y<not@my.name> wrote: > >> 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! > > 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. > http://www.mpeforth.com/powernet.htm > > Stephen >
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.
> lwip is very modular. One can disable TCP, and keep only DHCP, > ARP and UDP, for example.
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. Thanks, Boo
Hi Stephen,

On 5/7/2012 6:27 AM, Stephen Pelc wrote:
> On Sun, 06 May 2012 11:35:30 -0700, Don Y<not@my.name> wrote: > >> 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! > > 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.
Sure!
> Now our stack survives this environment. But then, > we charge for our stack. > http://www.mpeforth.com/powernet.htm
So, it's not a Linux/FreeBSD/etc. OTS stack! (didn't you just prove my point?) Does your instrument (application layer) *know* when it is under attack? Does it behave differently in those situations (again, application layer)?