editor's blog
Subscribe Now

Cache Clunker

We all know that server computing and embedded computing are different for lots of reasons, many of which can be summed up in one word: budget. Memory budget, performance budget, cost budget, etc. In other words, embedded systems have tight budgets, servers (and desktops and laptops) don’t. Much.

But occasionally something whacks you across the head in terms of the difference. Not long ago, there was an announcement out of MIT about a way to disguise memory access patterns for security. The deal is that, even when you’ve taken careful measures to encrypt data and otherwise keep prying eyes from snooping what’s being computed, those eyes can still monitor your memory accesses and learn too much. Hard to imagine, but apparently people way smarter than I am have shown this.

To be clear, this is positioned as an issue for cloud computing, where a set of resources may be handling delicate computing for many unrelated customers; because they share processors or memory or something, there’s the potential for, well, let’s say peeking at your neighbor’s exam paper.

Fundamental to this is the idea that multiple unrelated processes are running, something that doesn’t generally apply to embedded systems. However, if monitoring memory accesses can give away secrets, then that could still occur in an embedded device – its’ just that it might be someone breaking the thing apart and probing rather than some other co-resident process.

The solution proposed was to put an intervening piece of hardware in the memory access path. Each accessed memory address is placed in a tree, and when that memory is accessed, every address along its branch of the tree is accessed also. Then, after that, the address you really wanted is randomly swapped with some other address in the tree so that, the next time you access it, you’re traversing a totally different set of addresses.

In this manner, you’re completely shuffling your memory access patterns, making it hard (impossible?) to tell what’s going on if all you are watching is memory access.

The reason this smacked me on the head was thinking about the amount of work embedded designers go through to align memory carefully so that it packs nicely into the cache, minimizing misses and getting the most bang for each access. I struggle to think what this secure process (called “Ascend”) would do to a well-behaved cache.

Oh, and the other clue that we’re not thinking “embedded” with this? The performance hit is “only” 3-4X. To be fair, this is contrasted with other security ideas that apparently placed a 100X burden on access performance, and there’s no doubt that 3-4 is better than 100. But some embedded designers would give their left… eyeball to pick up 30-50% performance with one step.

I don’t know if there’s any way to map this idea into something more embedded-friendly; it’s intellectually interesting, and I’m not scoffing at its potential in the cloud, but unless I’m missing something (and comment below if I am), I’m not expecting this to come to a printer near me anytime soon. (And, again, to be fair, no one has suggested it should.)

You can find more in their release.

7 thoughts on “Cache Clunker”

  1. Pingback: 123movies
  2. Pingback: jogos friv
  3. Pingback: DMPK Testing
  4. Pingback: iraqi geometry

Leave a Reply

featured blogs
Jun 25, 2019
'Virtuoso Meets Maxwell' is a blog series aimed at exploring the capabilities and potential of Virtuoso RF and Virtuoso MultiTech. So, how does Virtuoso Meets Maxwell? Virtuoso now supports... [[ Click on the title to access the full blog on the Cadence Community s...
Jun 25, 2019
Over my 25 plus years of being a PCB designer I could not imaging going back to designing a PCB like I did in the late 90’s or even early 2000’s.  New technology is always being added to tools we use that helps simplify our job.  The key is making sure you'€™r...
Jun 25, 2019
During a recent visit to Seattle, I learned about the Great Seattle Fire of 1889. In less than 24 hours the entire business district, about 25 city blocks, its railway stations and several wharves were destroyed. Instead of moving the city to start over, they decided to rebui...
Jan 25, 2019
Let'€™s face it: We'€™re addicted to SRAM. It'€™s big, it'€™s power-hungry, but it'€™s fast. And no matter how much we complain about it, we still use it. Because we don'€™t have anything better in the mainstream yet. We'€™ve looked at attempts to improve conven...