4 ms·

Anyone else catch this gem: But if you are creating a chip that other people will create software for...then you don’t really know. This is in the context of

by bunnie 6y ago

Anyone else catch this gem: But if you are creating a chip that other people will create software for...then you don’t really know. This is in the context of assessing usage duty cycles of circuits for aging purposes. I can imagine an era of exploits that rely on "aging out" paths that were assumed to be rarely used. Like rowhammer, but persistent -- fire up a process on a random cloud instance, run a tight loop of code to wear out an exploitable path in e.g. SGX, rinse lather repeat until you have the coverage you need...

est31 6y ago
I think in the long term, we'll get away from the concept of general purpose processing units towards some units that have the right architecture and wear prevention to execute untrusted code and others which require less power but wear out more quickly. There will be domains for all those types of computing.
- Kye 6y ago
  That already happens, but they always seem to rejoin the CPU. GPUs are headed that way. Math coprocessors went back a long time ago. https://en.wikipedia.org/wiki/Coprocessor https://en.wikipedia.org/wiki/Coprocessor
  - est31 6y ago
    You can have the CPU share the die with the secure cores, but you'd need to figure out a lot of complexity, like dealing with memory access pattern leakage due to a shared memory bus. The less things you share, the less the performant parts need to care about security, and the secure parts need to care about performance.
hwillis 6y ago
Possible but unlikely IMO. For one thing it would be trivial to detect. To be a suitable attack surface it would need to wear out ~>100x faster than the most robust pathways (months instead of years). I am spectacle that manufacturing allows for that degree of flexibility. I would be more worried about two related issues: 1. If someone figures out how to focus execution that you'd normally assume distributed in a single area. The simplest example would be to write the first line of cache over and over again; that kind of thing has extensive protection but the principle is reasonable. I'm not sure what you'd use for this. 2. Aging related issues can be worked around; if a subunit loses performance you can give it more time to settle and reorder the pipeline around it. That would open up entirely new classes of timing attacks. You run a quick scan of every combination of execution paths (to find the biggest overlap of underperforming transistors) and you'll be able to make attacks using any number of extremely hard to predict timing combinations.
rawoke083600 6y ago
Clever :)

by bunnie 6y ago

est31 6y ago

I think in the long term, we'll get away from the concept of general purpose processing units towards some units that have the right architecture and wear prevention to execute untrusted code and others which require less power but wear out more quickly. There will be domains for all those types of computing.

Kye 6y ago
That already happens, but they always seem to rejoin the CPU. GPUs are headed that way. Math coprocessors went back a long time ago. https://en.wikipedia.org/wiki/Coprocessor https://en.wikipedia.org/wiki/Coprocessor
- est31 6y ago
  You can have the CPU share the die with the secure cores, but you'd need to figure out a lot of complexity, like dealing with memory access pattern leakage due to a shared memory bus. The less things you share, the less the performant parts need to care about security, and the secure parts need to care about performance.

hwillis 6y ago

Possible but unlikely IMO. For one thing it would be trivial to detect. To be a suitable attack surface it would need to wear out ~>100x faster than the most robust pathways (months instead of years). I am spectacle that manufacturing allows for that degree of flexibility. I would be more worried about two related issues: 1. If someone figures out how to focus execution that you'd normally assume distributed in a single area. The simplest example would be to write the first line of cache over and over again; that kind of thing has extensive protection but the principle is reasonable. I'm not sure what you'd use for this. 2. Aging related issues can be worked around; if a subunit loses performance you can give it more time to settle and reorder the pipeline around it. That would open up entirely new classes of timing attacks. You run a quick scan of every combination of execution paths (to find the biggest overlap of underperforming transistors) and you'll be able to make attacks using any number of extremely hard to predict timing combinations.

rawoke083600 6y ago

Clever :)