Wind River Blog Network

Detecting security problems – using static analysis to catch them early and less expensively

By Bill Graham

In my previous post I discussed the potential benefits in quality and costs that static analysis brings to software development. In addition to common coding errors, many of the bugs found by static analysis are potential security defects as well.  Buffer overflow, OS command injection, unrestricted string format and integer overflows are among the top 25 most dangerous security coding defects (according to the Common Weakness Enumeration (CWS) from the MITRE organization). These types of defects are common in C and C++ and are dangerous to correct operation in general but also pose significant security threats – often because the right exploit can lead to arbitrary code execution on the target. Once an attacker can execute code on your device, they can gain complete control, which might include reflashing the firmware, installing malware or rewriting the command and control software.

Continue reading >>

Making a Faulty Serial Port

By Jakob Engblom 

As noted before, one common use case for Simics is doing fault injection.  Fault injection is typically added to an existing system without changing it, since the goal is to maintain a fundamentally fast simulator when not injecting faults.  There are a range of mechanisms available in Simics to implement fault injection. This blog post will take a look at two such mechanisms and how they are used in the context of injecting faults on a serial port.

Continue reading >>

Secure Mobility Message Resonates at MILCOM 2011

By Chip Downing

MILCOM 2011 last week in Baltimore, MD was not only educational, but it was a watershed event.   Last year, it was a “coming out” party for custom Android devices; this year however, was the year where many companies are now using COTS hardware and software to their fullest extent, along the entire supply chain, from core to edge and user devices.   I believe this COTS adoption is driven by two powerful forces – the exploding capabilities of commercial tablet devices, and global military budget pressures.

The vastly increasing power and capability of commercially available mobile communications devices is simply amazing. Just a few years ago, almost everything in this military communications space was purpose built, and most commercial products were simply inadequate to address the rugged and complex system demands of military communications systems.   As seen at MILCOM 2011, this has officially changed -- COTS end-to-end communications domains rule.

So if all of these MILCOM vendors are not making customized hardware and software, what are they doing?   Wind River had over 500 people visit its booth at MILCOM this year, and most of the discussions I had with both suppliers and end users at the show were about increasing device security and leveraging high volume COTS components in demanding deployment scenarios.

Continue reading >>

Simics for Networked Systems: An Interview with RTI

By Jakob Engblom

Networked systems is one of the primary application areas for Simics. Simics can run many machines inside a single Simics simulation, and apply all Simics features to the system, not just to a single machine inside the system. This is something that Dan Poirot from Real-Time Innovations, RTI, has made quite extensive use of recently. It is a pretty cool use-case for Simics, so we arranged to interview Dan about his use of Simics.

Continue reading >>

Leveraging Virtual Platforms to Improve the Intel Product Lifecycle Process

By Eddie Glenn

An Interview with Atul Kwatra, Principal Engineer at Intel

My colleague Jakob Engblom and I had the opportunity to meet with Atul Kwatra, Principal Engineer at Intel recently.  Atul is responsible for driving virtual platform strategy and technical direction for the Intelligent Systems Group (ISG) at Intel.  ISG focuses on products for the embedded, networking, and communications markets. 

Specifically, we wanted to learn more about Atul’s vision on how Intel leverages virtual platforms to improve their product lifecycle to reduce risks, time to market, and costs.

Continue Reading >>

 

Improving Embedded Security: Proper Runtime Selection

By Bill Graham

Selection of secure components for an embedded system is key to a secure system. Leveraging a secure RTOS, middleware, virtualization and tools significantly reduces the effort and development costs. Moreover, there are additional benefits from using commercial-off-the-shelf (COTS) software components over Roll Your Own (RYO) code or self-ported and maintained open source code. Some of the COTS components worth considering include:

Continue reading >>

Why Simics Won't Run Super Mario

By Jakob Engblom

Emulating old computer gaming systems is a popular consumer-market application of simulation technology similar to Wind River Simics. There are a large number of emulators out there, emulating everything from old arcade games to the home computers of the 1980's to gaming consoles.  These emulators might seem quite similar to Simics on the surface, but in practice, the simulation technology employed is quite different.  You will never see Simics simulate an old Super NES running Super Mario Bros. 

It all comes down to the level of timing accuracy required.

To accurately run games written to run well on the very limited hardware of the 1980s, you need a fairly detailed simulation of the hardware circuits and their timing. 

Continue reading >>

 

Catching up at IDF 2011 - An Embedded Chat with Intel ECG

By Eddie Glenn

In case you missed it, the Intel Developer Forum (IDF) was held last week in San Francisco.  The Simics team was busy at IDF with multiple Simics-related events being held.   At IDF, we handed out free memory sticks preinstalled with Simics, models of Intel devices, and a hands-on tutorial.  This is a great way to quickly learn about Simics first hand.  We had a few left over, so if you want one, email us (simics_info@windriver.com) and we’ll send one over, while supplies last.

At IDF I had the pleasure to sit down with Tian Tian, a Senior Technical Account Platform Architecture Engineer at Intel.  He’s part of the Data Center and Connected Systems Group focusing for the embedded market segment. Working with customers on almost a daily basis has given Tian some great insight into what their current issues and challenges are.

Continue reading >>

Surfing the Web with Netscape 4

By Jakob Engblom

While looking into our old SPARC server targets for our new SPARC legacy offering, I  opened up a Simics demo checkpoint that we have had around for a long time (at least eight years). This demo is an UltraSPARC II running Solaris 9, and it shows how web browsers looked around 2001.  I used real-network to connect the machine to the Internet, and tried the default webbrowser - Netscape 4.78, built in June of 2001.

Continue reading >>

EOL Headaches! Simics SPARC Virtual Platforms to the Rescue!

By Eddie Glenn

OK, I’m going to date myself here and admit to my geeky side…

Back in 1993 (or was it 94?), I remember the excitement of my first SPARC workstation log-in info.   The company I was working for at the time was developing Ada compilers (yes Ada, not ADA, not A.D.A!) and Ada development environments.  Our customers almost exclusively used SPARC for our products, so having that power at my disposal was awesome…but it did take up quite a bit of my desk space!

For years, this was the predominant host platform that customers used to run our software.

Then times changed.

We began receiving requests to support Linux on an x86 host (surely, these ‘personal computers’ weren’t powerful enough to run OUR software, were they?)  But sure enough they were…and they ran our products darn well.

Fast forward to the present.

I now work for Wind River… specifically, on the Wind River Simics team.  In case you’re not familiar with Simics, it’s a full system simulator which simulates any target hardware system.  The Simics simulated target hardware (aka virtual platform) is then able to execute the exact same target binary as would run on the physical target hardware.

Continue reading >>

A Virtual Year

By Jakob Engblom

A while after I woke up my laptop today, I realized that the fan was pretty noisy. That typically indicates that the processor is working busy on something, and then I spotted Simics in the task bar. Checking in on that Simics showed that it was indeed running, and pausing it did lower the load on machine to the point that the fans calmed down. Turned out that while I was doing other things, Simics had been busily simulating away on one of my cores. Indeed, it had simulated what was almost a complete year.

As you can see on the right, the time indicator in the Simics control window shows that the target had executed for 7988 hours. That is close to 333 days, which is pretty close to a year. 

This was achieved in about 4 hours and 20 minutes of host time. Simics was moving time forwards about 1800 times faster than real time. Just how can that be?

Continue reading >>

How to Get Virtual

By Jakob Engblom

My blog posts about Simics tend to focus on how virtual platforms are used and what you can do with them. However, underlying all Simics use is the issue of getting a virtual platform in place. You need some kind of platform to run your software on in order to get the full benefit of Simics. Thus, creating virtual platforms is an important part of practical Simics use for many of our users.

We have been working with Simics for more than a decade, and we have learnt a lot about modeling along the way. The approach we have ended up with is a top-down methodology, where we start by investigating the target system as a whole from the perspective of the intended use cases, and then explore the details of each subsystem in order to determine how best to model it.  We then switch to bottom-up, applying an iterative modeling flow that delivers something useful as quickly as possible. During development, the goal is to always keep a useful (albeit probably incomplete) platform available at all times.

Continue reading >>

Software at the Toddler Stage

By Jakob Engblom

Developing software is an adventure where you explore the unknown, one line of code at a time.  At some point, the program reaches the stage where you can actually run it and try it - and that's where the real fun begins.  The software will sometimes behave as expected, but more often than not it will not. It will do something else, or crash, or generally do the wrong thing.  It is very much like a toddler - you can rely on it to some extent, but you never know when it will decide to do something unexpected, funny, or just throw a fit over something that would have seemed inconsequential.

I have spent quite a bit of time recently with toddler stage of Simics 4.6 (prereleases and betas).  The end result is really good and qualifies as an adult specimen (as discussed previously on this blog), but there was a lot of entertaining (and frustrating) things that went by as Simics 4.6 was a toddler. All software developers have stories like these to tell, but I just wanted to share a few of the funnier ones and give a glimpse of just how much work it is to get something like Simics running.

Continue Reading >>

Simics 4.6 Initial Impressions

By Jakob Engblom

Simics 4.6 is now out, and I would like to share some of my initial impressions of the new version.

The most visible new feature is probably the Simics source code debugger in Eclipse.  Source code debug might seem a yawn, but the way it has been integrated with Simics provides some new and unique abilities that at least I have never seen before in a debugger.  First of all, the debugger works on the system level.  An example is shown in the screenshot below, where we have two machines in the same Simics simulation - "Tune" is a dual-core Power Architecture P2020 running VxWorks, and "Herring" is a dual-core Intel Architecture Core 2 running Wind River Linux. 

Continue Reading >>

 

Twenty, Thirty, and Sixty Years Ago

By Jakob Engblom

In 2011, we mark several anniversaries here at Wind River and in the world of virtual platforms.  First of all, it is 30 years since Wind River was founded, in 1981.  Ten years later, in 1991, the first code of what would become Simics was written by Peter S Magnusson at the Swedish Institute of Computer Science.  Thus, Simics turns 20!  2011 also marks the 60th anniversary of the instruction-set simulator and virtual platform-based debug.

In 1951, Stanley Gill from the Mathematical Laboratory at the University of Cambridge published a paper called "The Diagnosis of Programmes on the EDSAC" in the Proceedings of the Royal Society of London.  In it, he describes how he created a single-stepping debugger for the EDSAC computer.  As an aside, the EDSAC was the first programmable general-purpose computer in the world, and the team around it built early versions of many of today's standard software tools such as the first bootloader and the first symbolic assembler, which was very visionary and an amazing feat of programming.

Continue Reading>>

 

Collaboration, Collaboration, Collaboration!

By Michel Genard

We have all seen reports, studies or have first hand experiences about projects falling apart. One of my favorite illustrations about this phenomenon is the well-known “tree swing picture.” Interesting to note that it dates from the 1970’s… I guess there are things that never change!

Seriously, humor often comes from a seed of truth. In the case of this comic strip, the core issue is communication and mutual understanding between teams.  Speaking the same language is not a guarantee that teams are intelligently working together. Even when using  plain and simple English (although, the existence of “simple” English is debatable), we frequently witness a lack of understanding between hardware and software teams. Why? 

Continue Reading>>

 

Wind River Turns 30: Looking Back and Moving Forward

By Tomas Evensen 

2011 marks Wind River’s 30th anniversary. The big 3-0…it’s a major landmark moment in anyone’s book. This year, we’ll be taking time to honor this milestone with a retrospective of Wind River’s history and also a series of employee stories.  In my many years with the company, Wind River always impressed on me the concept of  being bigger than just a single product or technology. There is an underlying spirit within our teams that constantly reaches for more, for some greater innovation. While many customers know Wind River for the VxWorks real-time operating system, it was always part of the vision to provide more value. In the early days, this entailed providing a TCP/IP stack and GDB for debugging. Later, additional value came from strong IDE support through Tornado and Workbench. Lately, it has been by providing a choice of operating systems, real-time or open source/Linux. 

A standout example that exemplified the vision of providing a more complete solution was when we embarked on creating a truly embedded hypervisor. In 2004, it had already become clear to us that virtualization would play an important role in embedded designs at some point in the future. In early 2005, Paul Borman who worked for me in the CTO Office created a very impressive prototype, called eCPU, that ran VxWorks and Linux on a single CPU and we learned a lot from that effort. When Johan Fornaeus came on board in 2006 through an acquisition (he was co-founder of Interpeak and before that, one of the co-designers of the Enea/OSE operating system), I had him leading a small nimble task force team to develop a hypervisor really suited for the embedded space. I felt we made a real breakthrough. This was not a repackaged operating system pretending to be something it was not designed for, but instead a truly unique approach to virtualization and separation. Over the next couple years, this small team created a scalable product with an extremely tight footprint, incredible performance, while at the same time being full featured for the common architectures such as Intel, Power, ARM and MIPS.

Back in those days, it was not clear to us when and how important multi-OS systems would be in the future, but today it is hard to imagine how to deal with these new complex systems without a hypervisor for embedded virtualization. Looking at my team’s achievement now, I still marvel at how the Wind River Hypervisor brings together multi-core and our various operating systems. Why choose between operating systems with different characteristics when you can mix them in one system? Throw in a networking stack optimized for multi-core and tools that can debug and find performance bottlenecks and you get a very capable foundation on which our customers can innovate.

By constantly looking to the future, Wind River continues to evolve and further build on its expertise. The ongoing push to innovate may have created interesting and complex challenges along the way. However, it has also resulted in celebrations and breakthroughs, and it’s undoubtedly a big reason why so many of us continue to stay on the ride. 

 

Kick-Starting the VxWorks 6.9 64-bit Port with Simics

By Jakob Engblom

Wind River just released the world's first 64-bit RTOS, Wind River VxWorks 6.9 for the 64-bit Intel x86 Architecture. This is a great achievement by the VxWorks team, and I am proud to say that Simics played a role in the development of the 64-bit port of VxWorks. Simics was used throughout the development in a variety of ways. One particular clever technique was used at the very start of the project to kick-start development and overcome the hurdle of getting hardware support in place.

An operating system really consists of two main parts. There is the kernel that manages the processors in the system, tracks the running tasks, deals with memory management, handles device drivers, fields interrupts, and provides services to programs. The kernel depends on the architecture of a system, but is fairly independent of any particular board or system. Then there is the hardware interface layer, or BSP (Board Support Package), that contains the drivers that actually make the OS run on a particular system.

The problem you face when starting to port an OS to a new architecture is that you have neither a kernel nor a BSP. To write the BSP, you need a kernel. To test the kernel, you need a BSP. Catch-22. Simics offered the shortest and cheapest way out of this cycle.

Continue Reading >>

Integration and Testing the Integration

By Jakob Engblom

The US National Highway Traffic Safety Administration (NHTSA) recently released a deep report into last year's issue with "unintended acceleration" on certain Toyota cars. They actually employed a team from NASA who analyzed the throttle control software using a wide range of cutting-edge tools. Reading their report gives a good idea for how embedded control software is developed, and the challenges inherent in validating it.

The conclusion is that the software is not a likely cause of the problems. The real meat of the report (and its appendixes) is just how this conclusions is reached, and what it says about the tools that could be applied to develop embedded software with greater confidence about its correctness.

Continue Reading >>

 

Working Faster with Less (Simulated) Sweat

By Jakob Engblom

One very important property of a virtual platform like Simics is its speed of execution. Without sufficient execution speed, a virtual platform is not very useful - users want to have results in reasonable time. Raw simulation speed (getting as many target instructions as possible simulated each second) is important, and Simics is certainly pretty good at that. It is not necessarily the case that the best way to get a job done faster is to process instructions faster. Sometimes, working smarter rather than harder is possible.

Typically, working smarter means doing less to achieve the same goal. If the simulator needs to do perform less work, the task will complete the task in less time.

One way of avoiding work is to do something only once, and reuse the result many times. In Simics, this is supported by checkpointing. For example, saving the state of a booted target to avoid having to redo the boot each time a target is put to use. A previous blog post discusses checkpointing in more detail.

It is worth pointing out that a checkpoint can be prepared by one person and used by many. This can be used to implement a nightly boot workflow, where a platform team configures and boots a standard setup for all developers to use. In this way, a complex target is booted only once for an entire project, rather than once per individual developer.

We can also use simulator backdoors to speed up certain tasks.

Continue Reading >>

 

Being Helpful or Simply Correct?

By Jakob Engblom

The other day, I spent some time getting a new operating system up on one of our Simics virtual platforms. The platform is stable, the hardware is shipping and it is being used with the very software I was setting up. However, as the operating system was booting, I got quite a lot of warnings from Simics about incorrect hardware settings. The operating system still worked, however, so why did we see all these warnings? Actually, when is it prudent to issue warnings to a user about suspicious uses of hardware? When building Simics models, we want them to be helpful and offer warnings as much as possible - especially for cases where some uses might be considered technically "correct" but are actually somewhat suspicious.

A virtual platform like Simics can print warnings to the simulation console when software performs operations that are not legal according to the hardware specification. Typical examples are writing to offsets in device register banks where there are no registers, changing the value of bits which are marked as "reserved", or writing illegal values to configuration registers.

Continue Reading >>

 

What I am Reading: Processor and SoC Simulation

By Jakob Engblom

A new book about processor and system-on-chip simulation recently appeared. Edited by Professor Rainer Leupers and Professor Olivier Temam, it features chapters from a wide spectrum of academic and industrial authors.

The chapters in the book each come from a particular company or research group. Each chapter addresses a different problem or technology, from a different perspective. This provides a good overview of the SoC simulation landscape, from processor architecture through hardware design to software development, system integration, and testing.

I had the honor to co-author one chapter, about Simics. In our chapter, I, Bengt Werner, and Daniel Aarno describe Simics, and try to explain why Simics is designed the way it is. 

Continue Reading >>

Shift Left

By Michel Genard

Whether developers or corporations use a formal development process or not, one of the most critical (and risky) milestones is to have access to the target hardware, on-time and on-quantity in order to get going with the software development. Adding to this dependency, the fact that software content has grown to a point where you have more lines of codes in any electronics systems than gates, the debugging, test and integration of these devices are by far the most challenging and overlooked activities. Often OEMs have no other choice than to make compromises to time-to-market and quality levels if they still want to release a product. Beyond trying to reduce cost of labor, deploying the smartest tools, and reusing commercial off the shelf components as much as possible, OEMs and system integrators are also looking for solutions to mitigate these risks and have found simulations such as Wind River Simics as the vector to literally “shift left” their life cycles, enabling them to develop software without the constraint of needing the target hardware to be available or even designed yet. 

Continue Reading >>

 

Iterative Hardware-Software Interface Design

By Jakob Engblom

Making good design decisions is hard, making bad decisions is easy. The best way to avoid really bad design is to actually work through how a certain design works in practice. One of my favorite examples is how Jeff Hawkins walked around with a mockup of the original Palm Pilot to tests its real feel through daily "use".

The same principle applies to software architecture. When you design a software component that other programmer's will use, the best way to make sure the design makes sense is to use it to accomplish something. Just creating an API and some unit tests is not likely to result in a design that is easy to use and that works well in practice. To me, this is one of the key insights of agile methods and iterative software development. By geting something half-finished into the hands of users and collecting feedback from actual use, the final design is much more likely to be good.

Continue Reading >>

Sometimes, You Have to Cheat

By Jakob Engblom

In a virtual platform world, cheating is sometimes a good thing. One man's cheat is another man's optimization.

Let's start with a story from the 1904 olympics in St Louis. In the marathon race, a runner crossed the finish line far ahead of the competition at an incredibly good time. It quickly became clear that he had cheated - he had been riding in a car for about half the race. This was obviously wrong, and he was quickly stripped of his "victory." Running a marathon is defined as covering the distance on foot. Using a car is not an allowed option. 

However, if the goal of the marathon race had instead been defined as "get from A to B in the shortest time" with no particular care for the mode of transportation, our cheater would have been hailed as the smart guy. The other runners who insisted on covering the distance on foot would have been considered dumb and behind the times. Thus, we can see that what is considered "cheating" really depends on the rules of the game and what is considered the essential goal of the exercise.

In a the world of virtual platforms, such considerations about the rules of the game are common.

Continue Reading >>

Debug, multicore, and more debug

By Jakob Engblom

I recently gave a talk at an industry-academia collaboration called ICES, Innovative Center for Embedded Systems, at KTH in Kista, Stockholm, Sweden. The theme was embedded multicore, and I realized that my role at these events seems to have changed. A few years ago, I would be the "embedded guy", defending the collective of embedded systems against speakers assuming that everything was a homogeneous shared-memory multiprocessor. This time was different, though. I have become the "debug fanatic."

There seems to be less need to explain embedded multicore nowadays. The academic community and multicore event participants seem to have finally accepted that there are systems out there that use more than one operating systems on a single chip (thanks to hypervisors, AMP setups, local-memory configurations, etc) and that we have hardware that is highly heterogeneous (with different makes and different types of cores all being part of a single system). In the final panel discussion, I found myself saying "build the hardware anyway you like, as long as I have good hardware debug support and introspection features".

I think this is indicative of a general truth: if you cannot debug it, you cannot build it. For multicore in particular, debug is scrambling to catch up.

Continue Reading >>

The Giggle Effect

By Jakob Engblom

Last week, I went to Tel Aviv to present at the CDNLive event taking place there. CDNLive is Cadence's user meetings, and while still being mostly about hardware design and classic EDA, they added a small track about embedded software where I was presenting. The trip was quite a climate shock, going from Sweden where the puddles had just started to freeze at night to the coast of the mediterranean with 30+ degrees. The welcome was also warm, and I really appreciate the effort the local Cadence staff put into organizing the software track and the good discussions we had before, during, and after the event.

Embedded software appeared on the CDNLive schedule since Cadence has realized the importance of software in the electronics products value chain.

Continue Reading >>

IMA on Simics: An Interview with Tennessee Carmel-Veilleux

By Jakob Engblom

After Summer, I have been in contact with Tennessee Carmel-Veilleux at the École de technologie supérieure in Quebec, who has been doing some really cool work with Simics.  Tennessee has learnt Simics very quickly, and has been very clever in how to apply Simics to the research problems he has encountered. In this interview, he tells us some more about his research and use of Simics. I prefix my comments with "JE", and his with "TCV".

Continue Reading >>

The Virtual Basil Fawlty

By Jakob Engblom

In the 1970's BBC comedy show Fawlty Towers, John Cleese manages to turn harmless everyday situations into total disasters, with very little effort. It is a marvellous example of how to inject faults into what could have been a smoothly operating hotel, and demonstrating just how things fall apart as the unexpected happens. Injecting faults isn't always that easy, unfortunately (or should that be fortunately)?

I recently read an article by Steve Chessin in ACM Queue about fault injection, where he discusses how the UltraSPARC II and III systems from the late 1990s and early 2000s supported hardware fault injection in order to test the ability of the system to recover from faults. In this case, injecting faults was a bit more difficult than roaming around in a hotel beating your hapless waiter with a frying pan or insulting the guests. In the article, he makes a very important statement:

Continue Reading >>

Physical or Virtual

By Jakob Engblom

When you explain what a virtual platform or full-system simulation solution like Wind River Simics is, a key part is that it runs the same software as a physical board or physical system. This does capture the core of the idea - but it does not mean that the virtual platform is only "just like the real thing".

Comparing virtual and physical systems is like comparing apples and apples, not apples and oranges: while apples are mostly interchangeable, they is certainly variation between them. Some apples are best for eating, some are better for making sauce, some are pie material, and some are best for fermenting cider. The type you select depends on what you want to cook. The difference between physical and virtual hardware is similar: they can be used as replacements for each other to some extent, but the connoisseur can make much better use of both by looking at the differences.

Continue Reading >>