3 ms·

I imagine we all agree that the entire idea of running crypto code from a dog-slow uC executing from flash is silly, but to continue the hypothetical... The wa

I imagine we all agree that the entire idea of running crypto code from a dog-slow uC executing from flash is silly, but to continue the hypothetical... The way old processors used to do XIP with constant random access latency is pretty much dead at this point for new designs. Semiengineering did a good article on this awhile back [1]. Even if there weren't usually a lot of invisible caching in the middle, flash cells usually don't have identical access latencies (worse, they change with age/write cycles!), and the AVR conditonal branch has data-dependent timings besides. At the design side, there's also a lot of decisions like burst modes that can introduce timing variations that can change with minor design revisions. Most of these aren't documented or even well understood by manufacturers. Truly eliminating architectural timing side channels is very, very difficult today. [1] https://semiengineering.com/what-happened-to-execute-in-place/ https://semiengineering.com/what-happened-to-execute-in-plac...

kragen 4y ago
I don't think there's anything wrong with running crypto code from a dog-slow μC executing from Flash, except that sometimes you might prefer the Flash to be mask ROM. This is a good article! I guess you're right that when you're running code loaded over a QSPI bus it's probably going to be cached unless you're using an old chip. So data processed by code loaded that way is subject to timing-channel leaks. However, I think it's very unusual for embedded NOR memory in a μC to have detectable variable access latency. As the article says: > As long as the operating frequency is slow enough that the flash access times can keep up, instructions can be fetched and executed directly out of the flash, otherwise known as executed in place. The original idea was that you didn’t need to buffer the instructions somewhere else before executing them. ¶ Embedded NOR memory is still alive and well, although today’s higher volumes are on nodes far from what would be considered leading-edge for logic. So, on-chip Flash is probably still fine. You probably don't want to try to make an AVR8 into an SSL accelerator, but there are plenty of applications where the ability to do crypto securely is valuable, even if it's very slow.
- AlotOfReading 4y ago
  On-chip flash would still be susceptible to whether the CPU uses burst accesses or other weird microarchitectural details. The former manifests as the 8th or 16th instruction having slightly higher real latency, for example. This sort of stuff is endless, which is why stuff like TFA that gets around the issue by simply removing the data dependencies before they ever get to the hardware is a better general approach if you're not going to do ASICs.
  - kragen 4y ago
    Slightly higher real latency? Are you talking about asynchronous CPUs like the GreenArrays GA144? Or saying that if you're running off the internal RC oscillator the clock speed will vary because the supply voltage varies depending on memory access patterns? Or by "slightly higher real latency" do you mean that an instruction will take 2 clock cycles instead of 1 or 3 cycles instead of 2? I don't think any of those are true on things like the ATMega328 AVR8 mentioned above or the Padauk PMS150C. Maybe you mean something else? Bitbanging protocols with tight timing requirements using cycle-accurate code is still a thing people routinely do on small microcontrollers, and it wouldn't work if instruction timing was as unpredictable as you're saying. Nevertheless, I agree that removing data-dependent branches is a better way to close timing leaks.

kragen 4y ago

I don't think there's anything wrong with running crypto code from a dog-slow μC executing from Flash, except that sometimes you might prefer the Flash to be mask ROM. This is a good article! I guess you're right that when you're running code loaded over a QSPI bus it's probably going to be cached unless you're using an old chip. So data processed by code loaded that way is subject to timing-channel leaks. However, I think it's very unusual for embedded NOR memory in a μC to have detectable variable access latency. As the article says: > As long as the operating frequency is slow enough that the flash access times can keep up, instructions can be fetched and executed directly out of the flash, otherwise known as executed in place. The original idea was that you didn’t need to buffer the instructions somewhere else before executing them. ¶ Embedded NOR memory is still alive and well, although today’s higher volumes are on nodes far from what would be considered leading-edge for logic. So, on-chip Flash is probably still fine. You probably don't want to try to make an AVR8 into an SSL accelerator, but there are plenty of applications where the ability to do crypto securely is valuable, even if it's very slow.

AlotOfReading 4y ago
On-chip flash would still be susceptible to whether the CPU uses burst accesses or other weird microarchitectural details. The former manifests as the 8th or 16th instruction having slightly higher real latency, for example. This sort of stuff is endless, which is why stuff like TFA that gets around the issue by simply removing the data dependencies before they ever get to the hardware is a better general approach if you're not going to do ASICs.
- kragen 4y ago
  Slightly higher real latency? Are you talking about asynchronous CPUs like the GreenArrays GA144? Or saying that if you're running off the internal RC oscillator the clock speed will vary because the supply voltage varies depending on memory access patterns? Or by "slightly higher real latency" do you mean that an instruction will take 2 clock cycles instead of 1 or 3 cycles instead of 2? I don't think any of those are true on things like the ATMega328 AVR8 mentioned above or the Padauk PMS150C. Maybe you mean something else? Bitbanging protocols with tight timing requirements using cycle-accurate code is still a thing people routinely do on small microcontrollers, and it wouldn't work if instruction timing was as unpredictable as you're saying. Nevertheless, I agree that removing data-dependent branches is a better way to close timing leaks.