Category: Uncategorized

We’ve been an engineering driven company from day one – something that leads us to be frustrated with “analysts” and reporters who seem unwilling to challenge marketing. For example, here’s how a recent Investor’s Business Daily article starts:

“With a fast-growing presence in everything from servers to cell phones, the Linux operating system appears ready for prime time. But is it ready for real time?

“MontaVista Software thinks so…”

Hello! Anyone there able to use Google? Why is it that reporters who write such stuff won’t do a little research so that they can tell their readers Linux has been “ready for real-time” in the most demanding applications for over a decade?

We’re finishing some tests on the IWill 8-chip 16 core server and seeing outstanding timing. RTCore can share Linux with cores or reserve them for real-time. On reserved cores the jitter time we have found to be fundamental never reaches two microseconds, no matter what the system load. On non-reserved, the IWill systems look like they are staying under 10 microseconds – we will see if that holds up over a few days. The fact that it has done so well is a tribute to AMDs fast interconnect architecture. Of course the utility of multi-core in high end control or simulation is that you can have dedicated real-time and powerful computing in the same box.
In RTCore (both RTLinux and RTCoreBSD) you can create threads on any processor and then create a thread that is “reserved”. While that thread is live, the BSD or Linux client is never scheduled on the thread’s processor core. So it is easy to reserve and free cores as demanded.

At under 1KW, the Iwill is not even that bad on power consumption (although we have means of bringing that down and newer processors should be cooler). All in all, it is obvious that a new era has arrived for the higher end of control systems, network devices, and other systems that blend computation with control. As we test out the real-time networking capabilities later this week, I will come back to talk about some other, possibly surprising, areas of application.

Holloway [22] points out that the typical argument in favor of formal methods (that software is bad, unique, and discontinuous; that testing is inadequate; and that formal methods are essential to avoid design flaws) is logically flawed, and unnecessarily complex (in logical terms). He proposes a simpler argument, which is both simple and logically valid: software engineers want to be real engineers; such engineers apply mathematics; and since formal methods is the mathematics of software engineering, software engineers should use formal methods.

from http://www.jpbowen.com/pub/fmics05.pdf

Can you imagine Maxwell or some advocate of his making a similar argument about why electrical engineers should use electromagnetic theory? The circular argument here depends on the declaration that “formal methods is the mathematics of software engineering”.  No it’s not. The mathematics of some engineering discipline helps engineers solve actual problems in that discipline.

So an exec from Claria (formerly known as Gator) heads off to the US Government’s . department of Homeland Security. As of today, if you Google “claria spyware” you get 44000 hits. The commercial (and governmental) utility of building security holes into software should never be overlooked. Security holes in software are a combinations of poor engineering and on-purpose engineering. The most straightforward methods of implementing digital rights management and most obvious techniques for automatic download of updates and remote management are to build holes which are invitations for security failures. And companies and governments anxious to gather data about citizens/consumers or to steer them towards favored sites are naturally impelled to exert their ingenuity to exploit and widen those holes.

Imagine designing an automobile with a motor that runs really well on a demonstration frame, with none of those heavy panels or safety devices, and only tested on a short flat track. Imagine an engineering team designing an automobile or truck deciding that since high torque is only needed rarely, they don’t have to worry about it. Imagine that team being surprised to find that as they add more to their prototype vehicle and start testing it on hills, it starts to fail more and more often. And imagine the management team who enthusiastically endorsed the use of a very low cost engine and similar tactics on project after project, complaining about the low margins and high cost of development in their industry where so many projects fail or need massive redesigns!

The natural tendency of an engineer is to assume that “security” is an engineering issue that reduces to a type of reliability. And the Common Criteria security document outlines
a solid engineering approach (written in astoundingly opaque bureaucratese) for assuring software is designed, developed, and tested to limit security failures. But “software security” means different things in other contexts.

Someone made serious
money from construction of the Maginot line.

1. Ross Anderson’s famous Why Software Security is Hard paper explains that “security” is often concerned with avoiding liability or blame while evading actually paying the costs of engineering security. For many people “software security” means “some hoops we have to jump though to satisfy an auditor or evade responsibility”.
2. GreenHills Software is using “security” as a method for trying to frighten people away from Linux. See my GrokLaw note for details.
3. The Digital Rights Management (DRM) people mean “Make sure we get paid, no matter how dangerous or insecure this makes the system from the customer point of view” See
   DRM and Security.

The lesson here is that “security” is more like “efficiency” than “reliability”. You’d be wise to find out “who gets the benefit from this meaning of security” before you sign up. Bruce Schneier has a great story.

The other week I visited the corporate headquarters of a large financial institution on Wall Street; let’s call them FinCorp. FinCorp had pretty elaborate building security. Everyone — employees and visitors — had to have their bags X-rayed.

Seemed silly to me, but I played along. There was a single guard watching the X-ray machine’s monitor, and a line of people putting their bags onto the machine. The people themselves weren’t searched at all. Even worse, no guard was watching the people. So when I walked with everyone else in line and just didn’t put my bag onto the machine, no one noticed.

It was all good fun, and I very much enjoyed describing this to FinCorp’s VP of Corporate Security. He explained to me that he got a $5 million rate reduction from his insurance company by installing that X-ray machine and having some dogs sniff around the building a couple of times a week.

I thought the building’s security was a waste of money. It was actually a source of corporate profit.
cite

So next time you see an impressive security credential or a virtual X-ray machine with patriotic slogans all over it, please look for the actual motivation and use. You might be surprised. In fact, the Common Criteria approach to software security asks for just this type of caution. You are supposed to do a thorough threat evaluation so that you can identify what your security needs really are instead of being stampeded into using someone else’s definition. Unfortunately, the Common Criteria documents are in exactly the kind of prose that you’d expect to see resulting from the collaboration of government security and standards organizations. See this note for more.