3 ms·

Computers already have the type of bus she's talking about. A lot of the low-level/boot level components use SPI/I2C/LPC/etc busses because they're so dead simp

Computers already have the type of bus she's talking about. A lot of the low-level/boot level components use SPI/I2C/LPC/etc busses because they're so dead simple to implement. For peripheral cards, PCI-e already supports I2C (well, SMBus technically, but they're close enough), so extension there would also not be terribly difficult. Finally, regarding FPGAs, they're as programmable as you want them to be. There are a number of applications where they do indeed become write-once chips that just handle what needs handling. Additionally, depending on what you're doing, FPGAs can be more than fast enough -- there are a number of them that support more interesting busses and interconnects, like built in 10-gigabit ethernet. So basically, you end up using the FPGA as a chip fine-tuned and protected based on your needs, not generic needs.

vrtx0 11y ago
My point is not that it's difficult to design a peripheral device that loads its firmware over SPI (or whatever bus). My point is that firmware for all supported devices must be maintained on the proposed external device. What happens when you add a new peripheral device to your laptop that didn't exist when your read-only SPI-connected firmware repository was created? How do you solve this with less risk than what we have now? Eliminate hardware upgrades and peripheral devices in favor of disposable computers and e-waste? FPGA: I'm afraid the FPGA argument still doesn't make sense. Sure, the community could create a "trusted" processor or SoC, but why use an FPGA over a custom designed processor? If the FPGA is reprogrammed at every reboot, we now have to ensure this process can't be exploited. If it's never reprogrammed, why use an FPGA in place of a CPU in the first place? I appreciate the input and perspectives, but I still don't see how the "laptop" described in the paper is advantageous. There are many promising paths that move us much closer to secure computing, but simply moving firmware around doesn't seem to move us forward.

vrtx0 11y ago

My point is not that it's difficult to design a peripheral device that loads its firmware over SPI (or whatever bus). My point is that firmware for all supported devices must be maintained on the proposed external device. What happens when you add a new peripheral device to your laptop that didn't exist when your read-only SPI-connected firmware repository was created? How do you solve this with less risk than what we have now? Eliminate hardware upgrades and peripheral devices in favor of disposable computers and e-waste? FPGA: I'm afraid the FPGA argument still doesn't make sense. Sure, the community could create a "trusted" processor or SoC, but why use an FPGA over a custom designed processor? If the FPGA is reprogrammed at every reboot, we now have to ensure this process can't be exploited. If it's never reprogrammed, why use an FPGA in place of a CPU in the first place? I appreciate the input and perspectives, but I still don't see how the "laptop" described in the paper is advantageous. There are many promising paths that move us much closer to secure computing, but simply moving firmware around doesn't seem to move us forward.