7 ms·

Voltage glitching is a serious but broadly orthogonal issue (and one that has a very different threat model than, say, a compromised software supply chain). We

Voltage glitching is a serious but broadly orthogonal issue (and one that has a very different threat model than, say, a compromised software supply chain). We actually do believe that opening this ROM would have prevented the problem because it is in fact glaring -- and the demographic for these parts really cares about this! So it seems highly likely that this problem would have been found many times over, and certainly would have been found in an early rev of the part that would have allowed them to fix it in a subsequent mask. We need open source ROMs (and open source firmware!), and we collectively need to stop finding excuses for vendors to not provide it.

bfrog 5y ago
The usual convincing argument comes in the form of large amounts of profit or lack there of along with liability waivers. Nothing else convinces companies faster. NXP is arguable one of the better micros to use as well, at least the Freescale derived parts. No amount of pleading or finger pointing is likely to work. Alternatively an open source asic based on open source cores and IP that you can have on an asic or fpga that people start having made in large quantities cutting out the middlemen might work as a serious spooky moment for the likes of microcontroller vendors. I can see it happening, riscv and litex make it dead simple to create your own custom soc on an fpga, perhaps with custom accelerators or I/O functions. It’s really quite amazing. Imagine taking a $7 or so max10 or lattice ice40 and rolling your own. No it’s not as efficient perhaps, but efficiency isn’t everything. Flexibility to correct things at a logic level, after the delivery, could be a godsend in some scenarios where difficulty in servicing or replacing hardware far exceeds the efficiency gains. There’s also some neat new chips that combine a hard cpu core, some hard ip for bus interfaces, and pl. perhaps the best of all if the pl is easy to use and program with open tools. See quick logic for example.
- rvense 5y ago
  FPGAs just have a different set of attack vectors. Maybe it's smaller and more esoteric, but they're not a silver bullet.
  - bcantrill 5y ago
    Agreed that they definitely aren't a silver bullet! We went pretty deep down the secure FPGA route -- they (such as there is more than one vendor, which there arguably isn't) are very, very proprietary. (Not only do you not have source code to ROMs, there are entire hidden cores!) Indeed, we ultimately abandoned that route for quotidian reasons: we couldn't get their proprietary toolchain to work reliably on a Linux box, and we were getting the runaround. Our belief was that if their support was so bad on something so simple, it was going to be much worse when we found more serious issues with the device. Our view was (and is) that open FPGAs are a necessary (but not sufficient) step to get us to secure FPGAs.
    - panick21_ 5y ago
      You might be interested in Precursor and the Betrusted Platform. https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor They are trying to have an hardware platform that can be inspected and it is based on an FPGA with a RISC-V Softcore. Its by Bunnie, and he great talks about the choices and why he made them: Keynote: Precursor - Trustable Open Hardware for Everyday Use - Bunnie Huang (https://www.youtube.com/watch?v=Fw5FEuGRrLE https://www.youtube.com/watch?v=Fw5FEuGRrLE) They are also doing their own Rust Message passing OS called Xous that might be of interest. https://github.com/betrusted-io/xous-core https://github.com/betrusted-io/xous-core
      - bcantrill 5y ago
        Interesting! I (obviously?) hold Bunnie's work in very high regard, but I had not seen Xous before. It seems to be similar in some respects to Hubris[0], but it's hard to discern its design center as most of the documentation appears to be forthcoming? Regardless, it's great to see more work in this important domain! [0] http://cliffle.com/blog/on-hubris-and-humility/ http://cliffle.com/blog/on-hubris-and-humility/
        panick21_ 5y ago
        Xous seems to be one step up from Hubris in terms of being oriented towards interactive applications and running full UI and dynamically loading applications. I have not enough knowledge about the underlying message passing semantics to give an educated differentiation. Maybe the most interesting feature is the Plausibly Deniable DataBase (PDDB). See: https://www.bunniestudios.com/blog/?p=6307 https://www.bunniestudios.com/blog/?p=6307 Here is some of the design intent behind Xous explained by its main designer: https://youtu.be/_pIr3Q7gqNI?t=959 https://youtu.be/_pIr3Q7gqNI?t=959 He described Tock as to small and Redox as to big in one of the talks.
thenewwazoo 5y ago
I agree with you! Is Oxide pushing the state of the art forward with any of the RISC-V vendors?
- steveklabnik 5y ago
  We’re not currently using RISC-V, though you never know what the future may hold.
Teknoman117 5y ago
How difficult is it to harden against voltage glitching? Couldn't the manufacturer build the chip so that as soon as the voltage dropped below some reference it asserts the reset line or cuts power or something?
- bri3d 5y ago
  Fast brownout detection into reset is a hard problem. Especially as process nodes shrink. So the answer is difficult and it's a fairly high effort "can't you just..." Here's some fun literature to read: http://nice.kaist.ac.kr/files/attach/filebox/711/003/International%20Journals/6080719.pdf http://nice.kaist.ac.kr/files/attach/filebox/711/003/Interna... http://hajim.rochester.edu/ece/sites/kose/files/conferences/glsvlsi_19.pdf http://hajim.rochester.edu/ece/sites/kose/files/conferences/...
  - R0b0t1 5y ago
    Depends where you draw your boundaries. Physical access is always going to be complicated, but on larger scales (and increasingly as you can make things smaller) you can have a cap tank that must accumulate enough charge to do reliable brownout detection before device powers on.

bfrog 5y ago

The usual convincing argument comes in the form of large amounts of profit or lack there of along with liability waivers. Nothing else convinces companies faster. NXP is arguable one of the better micros to use as well, at least the Freescale derived parts. No amount of pleading or finger pointing is likely to work. Alternatively an open source asic based on open source cores and IP that you can have on an asic or fpga that people start having made in large quantities cutting out the middlemen might work as a serious spooky moment for the likes of microcontroller vendors. I can see it happening, riscv and litex make it dead simple to create your own custom soc on an fpga, perhaps with custom accelerators or I/O functions. It’s really quite amazing. Imagine taking a $7 or so max10 or lattice ice40 and rolling your own. No it’s not as efficient perhaps, but efficiency isn’t everything. Flexibility to correct things at a logic level, after the delivery, could be a godsend in some scenarios where difficulty in servicing or replacing hardware far exceeds the efficiency gains. There’s also some neat new chips that combine a hard cpu core, some hard ip for bus interfaces, and pl. perhaps the best of all if the pl is easy to use and program with open tools. See quick logic for example.

rvense 5y ago
FPGAs just have a different set of attack vectors. Maybe it's smaller and more esoteric, but they're not a silver bullet.
- bcantrill 5y ago
  Agreed that they definitely aren't a silver bullet! We went pretty deep down the secure FPGA route -- they (such as there is more than one vendor, which there arguably isn't) are very, very proprietary. (Not only do you not have source code to ROMs, there are entire hidden cores!) Indeed, we ultimately abandoned that route for quotidian reasons: we couldn't get their proprietary toolchain to work reliably on a Linux box, and we were getting the runaround. Our belief was that if their support was so bad on something so simple, it was going to be much worse when we found more serious issues with the device. Our view was (and is) that open FPGAs are a necessary (but not sufficient) step to get us to secure FPGAs.
  - panick21_ 5y ago
    You might be interested in Precursor and the Betrusted Platform. https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor They are trying to have an hardware platform that can be inspected and it is based on an FPGA with a RISC-V Softcore. Its by Bunnie, and he great talks about the choices and why he made them: Keynote: Precursor - Trustable Open Hardware for Everyday Use - Bunnie Huang (https://www.youtube.com/watch?v=Fw5FEuGRrLE https://www.youtube.com/watch?v=Fw5FEuGRrLE) They are also doing their own Rust Message passing OS called Xous that might be of interest. https://github.com/betrusted-io/xous-core https://github.com/betrusted-io/xous-core
    - bcantrill 5y ago
      Interesting! I (obviously?) hold Bunnie's work in very high regard, but I had not seen Xous before. It seems to be similar in some respects to Hubris[0], but it's hard to discern its design center as most of the documentation appears to be forthcoming? Regardless, it's great to see more work in this important domain! [0] http://cliffle.com/blog/on-hubris-and-humility/ http://cliffle.com/blog/on-hubris-and-humility/
      - panick21_ 5y ago
        Xous seems to be one step up from Hubris in terms of being oriented towards interactive applications and running full UI and dynamically loading applications. I have not enough knowledge about the underlying message passing semantics to give an educated differentiation. Maybe the most interesting feature is the Plausibly Deniable DataBase (PDDB). See: https://www.bunniestudios.com/blog/?p=6307 https://www.bunniestudios.com/blog/?p=6307 Here is some of the design intent behind Xous explained by its main designer: https://youtu.be/_pIr3Q7gqNI?t=959 https://youtu.be/_pIr3Q7gqNI?t=959 He described Tock as to small and Redox as to big in one of the talks.

thenewwazoo 5y ago

I agree with you! Is Oxide pushing the state of the art forward with any of the RISC-V vendors?

steveklabnik 5y ago
We’re not currently using RISC-V, though you never know what the future may hold.

Teknoman117 5y ago

How difficult is it to harden against voltage glitching? Couldn't the manufacturer build the chip so that as soon as the voltage dropped below some reference it asserts the reset line or cuts power or something?

bri3d 5y ago
Fast brownout detection into reset is a hard problem. Especially as process nodes shrink. So the answer is difficult and it's a fairly high effort "can't you just..." Here's some fun literature to read: http://nice.kaist.ac.kr/files/attach/filebox/711/003/International%20Journals/6080719.pdf http://nice.kaist.ac.kr/files/attach/filebox/711/003/Interna... http://hajim.rochester.edu/ece/sites/kose/files/conferences/glsvlsi_19.pdf http://hajim.rochester.edu/ece/sites/kose/files/conferences/...
- R0b0t1 5y ago
  Depends where you draw your boundaries. Physical access is always going to be complicated, but on larger scales (and increasingly as you can make things smaller) you can have a cap tank that must accumulate enough charge to do reliable brownout detection before device powers on.