One-On-One: Mike Muller

Semiconductor Engineering sat down with ARM CTO Mike Muller, who first coined the term ‘dark silicon,’ to talk about what’s changing, why the company is focusing so heavily on software and security in addition to power, and how the will change design and vice versa. What follows are excerpts of that conversation.

SE: More effort seems to be going into the software side these days. Do we have to develop the software and modify the hardware to fit the software, rather than the other way around?

Muller: There are very different communities with different working practices. You’re not going to change them. They change and evolve over time at their own pace and in their own ways, but you’re not going to impose change on either hardware or software developers. What we’ve tried to do with mbed OS is ask the question, ‘Are there some fundamental things in the way RTOSes have been architected that are power inefficient?’ We’ve concluded that, yes, there are. Now you live in a world with multiple power domains in the SoC, and depending on the task you’re doing, you will have powered up different hardware components. Simply going through a round robin with different threads at different times, you are randomly moving those power domains. You have to power things up, power them down, then move onto the next one. In an event-based world where you remove some of the real-time constraints, you can say, ‘There are a set of events that have happened. These three all have the same set of power domain requirements. Let’s power up those domains, execute those three events, and then move to the next step, and then when nothing is happening, sit there with everything powered off.’ We’ve changed the way the RTOS works, and it does require the programmer to think about events rather than just tasks. We are asking programmers to see a change in the world.

SE: But isn’t that a fundamental shift? You’re bundling together tasks.

Muller: We’re grouping what can be done in the scheduler. They don’t have to see that. But they do have to think about when an event happens, what resources they need. But the actual coalescing of those events is something that happens in the scheduler. You don’t have to program that way. You can continue what you’ve been doing. But if you want to make it power-efficient, you do need to make that change. That’s the embedded programming world, which is a minor chunk of the software community. The applications that sit on top of that are agnostic. By the time you have five layers of abstraction you’re writing an application in an interpretive language. Where are the inefficiencies in that? There is no doubt those environments are inefficient, but they have evolved so you can develop very large, very complex and very scalable software solutions.

SE: And relatively quickly, right?

Muller: Yes. And should the world stop spinning, you can go back and find more efficient ways of coding it. But the world continues to spin.

SE: What you’ve done here, though, is more than what an RTOS typically does. You’ve built in select features out of what used to be middleware, added that to an operating system, and threw in some virtualization.

Muller: We decided we needed to do that in order to make secure devices. A minimum set of things has to be architected into the OS, not some add-on option. The whole focus on security and secure-bootstrapping and updates is something that has to be there as a fundamental. Otherwise you expose all of your IoT devices.

SE: So what you’re seeing is that security is a multi-dimensional end-to-end problem?

Muller: Absolutely.

SE: And it can’t be an afterthought. Like power, it has to be part of the initial architecture, right?

Muller: Yes. We looked at IoT and realized that IoT will be everything and everywhere and has to scale from tiny to big and include a whole bunch of different verticals. We were looking at what was common across all of them. What we came back with was that a large number are going to be running on batteries and they all need to be secure architected from the beginning. Those are the two fundamentals. It wasn’t just pick one of the standard RTOSes that are out there and go from there. Those RTOSes haven’t been written for that. There’s still a place for RTOSes, and there are many places where you do need to bring in that real-time element. But there are a lot that don’t need to be real time.

SE: In security the solution typically has been to narrow the channel in which an attack can occur. How do you do that with the IoT?

Muller: There are two sides to that. On the programmer side, we try to define the APIs that make it easy for the program to deal with security rather than exposing the individual components, which requires you then to assemble them in the right order. A lot of the security flaws we’ve seen involves people using the right tools in the wrong way and not realizing how the attacks come. By providing a higher level of APIs you’re making it easy for them to use the security. On the hardware side, it’s an open-ended story. If you really care about everything, you have to worry about whether someone is going to do a DPA (differential power analysis) attack on a piece of hardware to try to observe keys, and whether you need to have random noise generation on the power supply and put extra layers of metal and randomly change the bit ordering. For a particular application you may have built something that is secure, but you can attack anything. The question is what’s the effort needed to attack a system.

SE: That’s just the usual risk assessment in security, right?

Muller: Yes. And you might decide that the encryption between your small IoT sensor and your hub can be cracked for $1 million, but they’ll only get three bits of information. If you decide it’s where you’re keeping all of your bitcoins, you might want to spend more money. We’re not saying, ‘This is how you need to build your underlying hardware.’ What we are saying is, ‘The underlying hardware has to support these features, and depending on how much effort you put into implementation, you can change the attack threat and how much you need to spend to attack it.’ Any system can be cracked if you put enough resources into it.

SE: But with the IoT, the real risk isn’t just the stuff you’re worrying about. It’s the little things you don’t give much thought to, like your toaster. How do you deal with that?

Muller: Even if it’s just your toaster, you need a minimum level of security that makes it hard to hack. If you have to go into every house to find out the ID of that toaster in order to secure it, that’s not really achievable. But if you’ve made it hard for that toaster to download a random virus to access them all remotely, that’s good.

SE: Part of this involves a blurring line between a processor and an MCU, right?

Muller: This is absolutely more than just a processor. It’s a processor and some underlying hardware components. How you assemble them is up to you. But we’re also saying, ‘This is what a system architecture looks like if you want to take all that we’re offering, from server side to client-side device.’ It’s not just about the device. It’s about what the combined architecture is and how that matches with the server side. It’s a system architecture, not just a piece of hardware.

SE: And that system is end-to-end?

Muller: Yes. The example I use is, ‘Here’s the little data coming out of an embedded device, here’s how I get it into the cloud server.’ IBM or anyone else on the other side doesn’t have to worry about toasters or coffee machines. We’re not saying we’re going to do anything with the data, like data mining or where you’re going to place adverts. That’s a big data problem. We’re just trying to make sure the little data gets to where it’s supposed to go.

SE: But what do we do when we have driverless cars connected to the Internet and the power and Internet goes out, which does happen in earthquake-prone areas?

Muller: It’s about how do you design devices that fail soft. With driverless cars, you bring everything to an orderly stop and then put on the spare steering wheel.

SE: Let’s swap topics. The IT server market traditionally has been very cautious about making changes because a lot is at stake. What’s broken or disrupted enough to allow ARM a foothold?

Muller: It’s more than just the server market. It’s also enterprise server networking. There is as much change happening in networks as there is in servers. There’s a lot more diversity in networking and there’s a whole movement toward virtualization of networking. How people provide their own virtualized structure is changing.

SE: What do you mean by virtualization of networking?

Muller: If you look at a network of base stations, what is the network installed to make sure those base stations are connected to a core network? It’s not just a question of running Ethernet to all of them. They actually have specialized hardware for the underlying fabric. That is going through a change. How does that specialization happen? How much do you generalize it? And if you virtualize that network, how do you actually implement it? There are big changes in how people are deploying groups of structures in networks, and there is a big opportunity there for ARM-based SoCs. It isn’t one-size-fits-all in networking. And there is a bit of a blur between what’s networking, what’s storage, and whether networking is integrated into your server backplane or whether it’s separate. Intelligence is being pushed into the storage so it can be distributed around your network.

SE: It’s the same for all data, right? Where do you put it and how do you access it?

Muller: Right. And how many copies have you got replicated around the world. There are a lot of changes involving the rise of mobile devices and the increases in content, rather than just Web browsing. It’s changing how some of the underlying fabric gets built. Change is opportunity. As important as a technology change is the business model.

SE: The business model, or at least the need for something new, typically comes first.

Muller: Yes, and it’s a business model that ARM enables, and it’s driving some of the change.