Archive for Felix Baum

9 April, 2015

Big question on security of embedded devices.

An embedded device is only as good as the firmware/software running on it.  Icon Labs and Mentor Graphics have partnered to develop a security framework for industrial automation systems. Alan Grau ( of Icon Labs and I hosted a webinar to address this topic: Developing Industrial Control Systems which meet Security and Regulatory Requirements , which is viewable on demand.

We talked about a security framework that provides a number of security features to protect the device from runtime attacks. During the session, a question was raised about the ways a framework could be used to prevent certain type of attacks in which a hacker replaces the firmware on the device with their own malicious firmware. The question is very relevant as this technique was recently experienced in the real world to reprogram point of sale terminals at retail vendor causing a data breach exposing customer account information.

This question brings up a very important point.  If a hacker is able to replace firmware then they can disable security features and all bets are off.  All of the great capabilities of the security framework could be bypassed.  As such, secure boot is a critical security feature to ensure that embedded devices are running valid software from the OEM, and preventing these types of attacks is extremely important.

How does secure boot work?

Secure boot starts by executing a first stage boot loader stored within secure flash memory provided by the TPM hardware.  This boot loader is stored within protected memory so it cannot be replaced by hackers.

Also stored in protected memory along with the first stage boot loader is the signature and crypto key for the second stage boot loader.  The first stage boot loader calculates the signature of the second stage boot loader using the hardware crypto support and crypto key.  If the calculated signature for the second stage boot loader matches the stored signature, we know the second stage boot loader is valid and allowed to run.  The second stage boot loader repeats this verification process before loading the operating system.


Operating systems supporting loadable applications or tasks can repeat this process yet again with each application before it is loaded.  For RTOSes that are downloaded as a single monolithic image containing both the OS and apps in one image, this process does not need to be repeated at the OS level.  This process can be extended to validate libraries or data files stored on the device.

SoC Features with Root of Trust

The good news is that many silicon vendors provide features in their SoCs to enable secure boot and root of trust. The bad news is that implementation varies from vendor to vendor and even from device to device from the same vendor. As such, a turn-key, one way of doing things approach would not work, but we have worked with major silicon vendors to make sure that framework presented in the webinar could be used with their devices and use the hardware capabilities to anchor the software to the hardware while establishing the chain of trust.


, , , , , , , , , , ,

6 April, 2015

Driving to work this morning, I heard a story on smart water meters and how they are changing consumer behavior and the actual annual usage.

The Long Beach (Southern California) water utility announced the effectiveness of their water metering projects using an easily installed electronic device. The data collected from the deCapturevice via wireless connection was monitoring water use exceeding 5 minutes in continuous duration. The utility provided consumers with reports that provided insight on the water used, when and how much. With the increasing cost of water, this program along with increasing costs for water has helped incentivize behavior modification, for example Long Beach has seen an annual decrease of 6% in water used.

The widespread use of advanced metering devices in homes and manufacturing facilities that are connected to the infrastructure support various utility resource use intelligence. The smart utility efforts have been funded by private and government resources, and even deployed under mandate in some parts of the world.

More commodities and basic daily living resources are being monitored and our awareness builds while all the details contributes to the big data explosion long discussed in IoT. These deployments also provide a meaningful use of technology to change our world.

The key concern that has risen to the top of mind is security, the connectivity enabled in end-point devices broaches very real issues that can be addressed in the device design and the connected infrastructure to secure the device and their point in the network. Preventing and mitigating potential vulnerabilities requires some extra steps that can offer reliable device operation and data transport. Read more about securing modern devices in this white paper or watch an archived webinar about developing embedded devices for IoT applications.

, , , , ,

27 November, 2013

At Tokyo Embedded Tradeshow last week, the Mentor ESD team was very busy as we had many medical customers stopping by our booth to find out how Mentor Embedded Hypervisor can help them to address regulatory and ethical issues with protecting sensitive patient information and industrial customers to make industrial equipment secure and more reliable.

The explosion in medical devices is due in part to the growing aging population that expects ambient, assisted living to support modern lifestyles mandates that these devices are easy to use and deploy, with similar user experience as consumer electronics. Using embedded virtualization on the latest multi-core silicon parts from ARM, companies can now securely segregate the general purpose operating systems from the real-time systems. Linux or Android running on these medical devices will be allowed to communicate securely using ARM TrustZone APIs with security-sensitive data such as patient records, while the real-time functions such as diagnostics and patient monitoring take place elsewhere on the device, simultaneously. For example, in many such devices we have seen the need to maintain a very precise and deterministic polling task to sample a particular sensor. Any jitter in this sample date would jeopardize the algorithm and invalidate the information computed based on it producing the wrong measurement.  It is prudent to segregate this type of tasks and algorithms to a separate virtual machine instead of wrestling with a problem of making Linux or Android to meet stringent timing requirements.

In a highly competitive manufacturing environment, many companies cultivate a constant focus on cost cutting while maintaining production throughput and employee safety. To lower operating expenses, a large part of which are the purchase and support of industrial systems, they maximize the length of time they can stay on a particular control system platform for two reasons: increase ROI and reduce the amount of disruption to operations. Virtualization is a key technology that can assist in reducing the frequency of hardware refreshes, the cost of each refresh, and the impact to process operations when a refresh occurs, each of which accomplishes the goal of increasing ROI and mitigating operation disruptions. Tasks, in these industrial control systems, that require real-time and deterministic execution can be given priority through the separation provided by the Hypervisor product. All while the Android or Linux based applications responsible for user interface, image or signal processing or communications to a cloud based server could use this connectivity safely and reliably in a separate virtual machine.

Please take a look at my previous blog entries and the webinar on this topic. Feel free to comment and contact me directly if you have additional questions.

, , , , , , , , , , ,

14 November, 2013

A very good turnout at the webinar I have recently hosted on the topic of Enabling Multi-OS Embedded Systems with Hypervisor Technology. During webinar, I talked a bit about trends in the embedded industry, the way hardware and software vendors are dealing with these trends, walked through the most popular Operating Systems configurations – SMP, AMP and sAMP, highlighted the benefits of embedded virtualization, talked about capabilities of Type1 hypervisor and how using it along with ARM TrustZone technology can help developers to build reliable devices.

If you missed it, no worries, you should be able to access it at this link. Due to the interest to that topic, I have attempted to wrap up the presentation in under 40 minutes leaving ample time for the Q&A. Unfortunately, I was not able to answer all of the questions raised during the event and will be using this blog to post answers to the questions that went unaddressed.

During my presentation, I have described a three use more popular use cases for embedded virtualization:

  1. Over-subscription – when a developer needs/wants to run more payloads than cores available. A good example of that would be running Linux and RTOS next to each other on a single core.
  2. Consolidation – when multiple, independent in the past payloads are being brought together to run on a single multi-core part.
  3. Separation – when sensitive information, resource or algorithm needs to be protected from the rest of the system to ensure security, reliability or safety.

I have asked participants to vote on why on their project they would like to use a hypervisor and although only a subset of folks attended have participated, got these answers:

poll results

It was also interesting to me to find out that overwhelmingly folks are considering for the next project to use ARM architecture:

And when asked about numbers of the cores they plan to use, they responded this way:

All in all, I was not surprised by these results as they correspond very well with my own observations of the trends in the embedded industry.

, , , , , , , , , , , , ,

25 October, 2013

I am very excited to post my first entry to the  embedded blog and share the announcement for the product that I am managing. As some of you are aware, on October 24th 2013, Mentor Graphics officially launched Mentor Embedded Hypervisor via announcement found here  –

The upcoming product release will contain support for Multicore and MultiOS environments, ARM®TrustZone® and TEE, ARM Cortex® A9 and A15 architectures. Please go to page to learn more the about capabilities or signup for my upcoming public webinar:  Enabling Multi-OS Embedded Systems with Hypervisor Technology.

In the meantime, for the ARM Techcon (which will take place in Santa Clara on October 29-31, 2013)  we have put together a demonstration system to highlight some of the capabilities of the Mentor Embedded Hypervisor. It is based on a Freescale® i.MX6 quad core board that was booted with Mentor Hypervisor. The hypervisor partitioned the system into 2 virtual machines.

  • First virtual machine is using 2 Cortex A9 cores and booted with Linux kernel. As an application we are running accelerated graphics package of the 3D Instrument Cluster. It uses 3D objects and many OpenGL ES effects, by exploiting the hardware GPU for a more sophisticated look. The graphics is displayed on HDMI display panel with 1280×720 resolution.
  • Second virtual machine booted Linux kernel as well. It uses Digia Qt graphics package with 2D graphics to run In-Vehicle Infotainment system. This Virtual machine uses LVDS display panel with 720×768 resolution and supports user interaction via touch-panel. This Virtual Machine also supports audio playback.

Amongst many of the features of the Mentor Embedded Hypervisor is the capability to provide partitioning of the system and isolation of resources. If you visit Mentor Graphics booth at the ARM Techcon event, you will see how we can trigger the re-boot process on the virtual machine that controls the IVI system. You will be able to observe in the terminal window, the Linux® being rebooted, the graphics package re-initializing and Qt based application being re-launched, all while the virtual machine that manages the instrument cluster is still running un-affected.

If malware was downloaded into the IVI system running Android or Linux and caused it to crash while you are driving the car, the VM can recover without disturbing the cluster VM where car critical applications are running.

, , , , , , , , , , , , ,