Cache side channel attacks: CPU Design as a security problem | Hacker News Reader

Cache side channel attacks: CPU Design as a security problem

cyber.wtf

51 pointsingve14 comments

I am reminded of something from Levy's Artificial Life book. In Thomas Ray's Tierra artificial life simulation, one of the viruses learned to exploit information left over in the virtual processor's "registers" from a previously executing virus.

I had something similar happen in an artificial life program. My collision resolution had a bug in it, so organisms exploited that to make it easier to reproduce. (Everyone could occupy the same square, so that made it much easier to find mates. It's kind of like SF.)

Where would one go to get started in building artificial life programs? I find the idea very fascinating.

Where would one go to get started in building artificial life programs?

Just do it. You probably won't break any new ground, but it will be fun. You can dig up Levy's book from the library. There's also "Wa-Tor" from an old Scientific American article. You could probably knock this out very quickly drawing on a browser Canvas in Javascript.

There's quite a bit out there on Genetic Algorithms.

Good god those color choices are terrible.

I refrained from commenting earlier but I've upvoted you because something about that thin font + red + gray background was very difficult to look at, i.e. literally my eyes were moving elsewhere involuntarily. I'd be interested to know if there's a known color selection phenomena that causes this kind of reaction.

It's a form of grid illusion[0] that makes you take notice of movement in the background.

[0]: https://en.wikipedia.org/wiki/Grid_illusion

I thought it was my particular lcd that headline color combination is literally difficult to look at. yeouch

I switched to Safari's reader mode to subvert that unreadable design.

This is a problem for designing hard real-time systems as well; in order to ensure predictable timing, you often end up being forced to disable caches completely.

Does that impact what type of memory topologies that you use too(I.E. SRAM only)?

I've only done soft-realtime and disabling caches sounds crazy to me on anything reasonably fast.

Unless you can fit your entire application into faster RAM, you usually can't do SRAM only. And yes, it is crazy, but hard realtime is a whole different ballgame. Fortunately, your actual deadlines are usually pretty lenient, and you can often devote the core to a single task, so being slow isn't as big of a concern as you'd think. Another common thing you can do is maintain an SRAM scratchpad or two, sometimes with dedicated circuitry for handling the really latency-critical part, so you have full control over what goes in cache.

Oy.

That reminds me a bit of the SPUs on the PS3 where you had only 256kb of local memory and had to DMA everything in/out. How do you deal with MMUs? Do you just manually map each DRAM bank to a specific task and not even try to share them?

> How do you deal with MMUs? Do you just manually map each DRAM bank to a specific task and not even try to share them?

Pretty much.

Oh man, fun times.

Thanks for the insight, seems like an interesting space. I've done the 8-bit micros which are somewhat hard-realtime but never something at a larger scale.

Reply on news.ycombinator.com