@MrChromebox I’m thinking of this mostly from a theoretical perspective and I’ll outline my thinking below. Perhaps my line of thinking does not line up with the reality of the situation, in which case please say so and to what extent.
Let’s say each Librem motherboard has a set of chips C and a set of peripherals P attached. Let’s say peripherals have access to some kind of bus in this case. Let’s say there is a subset chips in C which have some persistent memory that can be flashed, let’s call this subset Cf. Let’s say there is a subset of peripherals which have some persistent memory that can be flashed, let’s call this subset Pf. NOTE: I’m not going to distinguish between chips which can be flashed from software, which I would consider more critical, than those which require physical access and a dongle because I believe HEADS should protect against Evil Maid attacks where the attacker has physical access to the machine.
Let’s say the persistent memories on these chips and peripherals hold some code or information which is used to operate the chip/peripheral. And let’s call this code or data “firmware” for brevity.
In my line of thinking, HEADS needs to calculate cryptographic hashes for all of the chips in Cf and all of the peripherals in Pf during the boot process and validate them against known good values.
Failing to do so, means there is a theoretical probability the skipped chips or peripherals could be used to store APTs.
Obviously, there is a game theory angle here by which using HEADS to validate any subset of Cf and/or Pf represents an iterative improvement over the current state of affairs - and I applaud Purism for pursuing this technology because of this angle…
… but … the more of Cf and Pf covered by HEADS the better I’ll sleep =)
Comments and corrections appreciated.