5 ms·

I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either c

• viraptor 11y ago
  > or the system must provide a mechanism that 'sends' this firmware to all peripherals before booting the system. That's pretty much what they note in "The SPI flash chip" section and what's replaced / muxed from the trusted stick in "Putting it all together" (page 15). SPI is that firmware provisioning component here.
• detaro 11y ago
  FPGA: You would reprogram the FPGA on each boot from the trusted source. The performance/energy issues remain of course.
• rolandr 11y ago
  > vrtx0 1 hour ago | parent I'm probably missing something, but I don't see how this is feasible. Moving all firmware to a device that lives on an external bus means that you must either create a 'trustworthy' distribution channel for all supported firmware (including all system components and peripheral devices), or support only a select few devices and forbid adding any new peripherals. In general, most of the firmware needed for system components is streamed from the main SPI chip to the various components as they are configured by the main system BIOS. Thus, there mainly is a single chip we are concerned about. However, the author identified a second embedded controller )EC_ flash that is also usually present, so we end up being concerned about 2 flash modules. The author addresses other firmwares - the main one being discrete GPUs - and suggests having a system that does not include them. > Also, I have to disagree that FPGAs are ideal for the architecture proposed by this paper. Performance and state issues of an FPGA aside, they're field programmable, which seems more vulnerable than 'microcode updates'. Of course, you could just disable field programming, but why even use an FPGA in the first place? If your only interface between the computer and the FPGA is a three wire interface that emulates an SPI chip, that does not provide any vector for reconfiguring the FPGA. The bitstream for configuring the FPGA is provided via a completely separate set of hardware pins.
  • grhmc 11y ago
    > The bitstream for configuring the FPGA is provided via a completely separate set of hardware pins. FPGAs don't take any permanent form, and read their configuration from an EEPROM. If state is evil, the EEPROM would have to be on the stick itself.
• Sanddancer 11y ago
  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.
• nickpsecurity 11y ago
  The solution to the "field-programmable" part is called "anti-fuse" FPGA's. They're programmable only once. Look them up.
  • vrtx0 11y ago
    Thanks for the info! I still don't see how an FPGA (with or without anti-fuse) is any better than fabricating a processor. The paper seems to state that FPGAs are a better option than x86, ARM implementations, etc. I'm starting to think I misinterpreted that section, or the limitations and trade offs of FPGAs weren't fully considered.
    • nickpsecurity 11y ago
      That's because you might think designing hardware is as easy as coding software. There's a world of difference. ;) Decent intro to ASIC design with FPGA comparison and a pricing chart to illustrate the high costs: https://www.u-cursos.cl/ingenieria/2010/2/EL653/1/material_docente/bajar?id_material=305352 https://www.u-cursos.cl/ingenieria/2010/2/EL653/1/material_d... Note that the tooling that makes this possible, esp design synthesis, can run to $1+ million per user per year. Some are merely upper 5-digits to lower 6-digits. Really inexpensive. Mask costs have come down for older nodes in recent years because fab equpiment is finally paid off. Yet, you're still talking millions for a full SOC with modern features. And it will be slow as hell because it's on old stuff if it's a CPU. That the market demands more speed, more functions, less power, etc is why they keep dropping to smaller node sizes. Each one adds new effects that try to break the chip. The electrons even tend to leak out of the transistors. Can't even assume they'll stay in them haha. Actually, from what I've read, it appears chips are broken all over on latest nodes with lots of logic there just to correct that. Here's an example of the crap they have to do at 28nm, which isn't cutting-edge anymore: http://electronicdesign.com/digital-ics/understanding-28-nm-soc-design-arm-based-cores http://electronicdesign.com/digital-ics/understanding-28-nm-... So, you need specialists that make big $$$, $1+ million in EDA tools, mask costs at millions a set per trial, and other stuff like boards (regularly 6 digits on kickstarter). That's for an ASIC. An FPGA's design flow ends at the RTL simulation part, has no mask costs, free to cheap EDA, and often has pre-made boards you can use. Price you pay is lower-than-ASIC performance, higher watts, and very-high per unit price. Still a better deal on lots of systems plus can be converted to a hybrid later (see eASIC Nextreme). Hope that clears up why one would choose a FPGA over an ASIC. All that said, the difficulties they're facing in this case is largely due to choice to stay on Intel, Xen, and other difficult-to-secure crap. If one forgoes those software, then one can use Cobham-Gaisler's SPARC SOC's since they're designed for easy modification & already at quad-core. Academics made many secure CPU's out of his stuff. Just gotta license it, modify it, and run it through later parts of ASIC flow. FPGA still cheaper, but you can FPGA it too. :)