When the hardware’s got your back - Embedded.com

When the hardware’s got your back

Intel processors catch bugs and malicious code in real time.

One of the things I’ve always liked about 32-bit Intel processors are their built-in hardware-protection mechanisms. Sure, any processor can run your C code. But how many can catch programming errors at run time? Automatically, and with practically no software intervention? It’s nice to have a chip that’s got your back.

What I mean is, every x86 processor from the ’386 onwards has at least three hardware safety nets: the memory segmentation, the privilege hierarchy, and the built-in task management. (There are others, too, but that’s for another day.) All three catch errors in my code – or other peoples’ code – without any help from me. I can’t think of another CPU family that has so much built-in safety checking.

Let’s start with memory segmentation. Anyone who’s ever programmed an old x86 chip knows about segmentation. Code is kept separate from data, data is separate from stacks, stacks are separate from code, and so on. So right off the bat, the chip keeps things Kosher, and automatically avoids intermixing dissimilar blocks of memory. That prevents you from accidentally jumping into the middle of your stack space, for example, or from writing variables into the middle of your code. Nice.

But it gets better. You also get to tell the chip how big each of those segments is, and it will automatically prevent you from running off the ends. For instance, if your code segment is exactly 0x34FF0 bytes long, the processor will absolutely refuse to fetch instructions from address 0x34FF1. Nor will it allow you to “underrun” the code segment by fetching from a lower address. You can have as many code segments as you want, and each one can be any arbitrary size. The chip silently protects them all. It’s like automatic run-time bounds checking, but without the overhead.

The second bonus is the privilege-level protection mechanism. Every code segment gets assigned (by you) one of four privilege levels. Lower-privileged code can call higher-privileged code only through defined “call gates,” a special type of jump/call instruction. That prevents untrusted code from usurping the advantages of more trusted code. It’s a great way to separate the operating system from the drivers, middleware, and applications. I generally assign the lowest privilege level to anything that’s downloaded or that didn’t come straight out of ROM, just in case.

What’s nice about Intel’s privilege protection is that it’s baked into the silicon, so you can’t hack it, spoof it, or recode it. It’s a fundamental part of the chip and can’t be disabled or sidestepped. (You can assign all your code to the same privilege level, if you like, effectively neutralizing the protection, but that’s your decision.) This built-in mechanism is a lot more solid than the software-based equivalents you see in most operating systems.

Finally, there’s the built-in task-management feature, which I think is really underrated and underused. Most embedded systems have tasks, but most of them use some sort of software task scheduler or RTOS to manage them. Fair enough, but did you know that your x86 processor can probably do that for you automatically, in hardware, for free?

You can tell the chip what segments of code, data, and stack comprise a “task,” and you can have as many tasks as you want. When it’s time to switch tasks (on a timer interrupt, for example), the processor will – all on its own – stop executing the current task, freeze its state and all of its context, load the new task, and start executing from where it left off. All of this is done in hardware, with virtually no software overhead to speak of. It’s remarkable. Once you set up all the parameters and press the Go button, it’s all automatic.

I could go on (and often do…), but there’s a summary document of how this all works that you can download from here. More important, you should review the processors and support logic that Intel offers for embedded designers. There’s a whole subsection of Intel’s website devoted to embedded design, called – surprise! – the Embedded Design Center (EDC). Check it out.

Jim Turley is the founder of Silicon Insider and is editor of Electronic Engineering Journal.  He is working with Intel on a series blogs for its Embedded Design Center, of which this is blog 2. is    of that series. You can reach him at . His twitter handle is @ChipGuy

7 thoughts on “When the hardware’s got your back

  1. The article makes this sound like these are all magic functions only available on Intel devices.

    Pretty much all CPU architectures provide memory management and such. Not sure what point is being made here.

    Log in to Reply
  2. I think the point being made is something along the lines of “Please stop buying ARM processors!” I.e. the article is marketing nonsense. How much does an engineer get paid to write this stuff?

    Log in to Reply
  3. Unfortunately Intel has a long history of dropping the embedded community in the soup. On top of that, Intel seems to understand the high margin markets well, but embedded is a low-margin business. And the real kicker is that Intel don't provide the variet

    Log in to Reply
  4. This post wasn't about the MMU; every processor has one of those, as you point out. Instead, this was about the built-in hardware protection mechanisms that are unique to the x86 architecture. Any chip's MMU can stop a write to memory that's off-limits, bu

    Log in to Reply
  5. Totally agree that Intel (and AMD and some others) had a very on-again, off-again attitude toward embedded CPUs. That was a deal-breaker for many embedded designers in the 90s and later. But I think (hope?) that the company has (a) learned its lesson and (

    Log in to Reply
  6. What would be interesting would be if Intel stopped trying to FUD against ARM and instead tried to make their own ARM offerings.

    Intel are by far the process leaders and have amazing manufacturing ability. Without that they could not get anywhere as good

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.