I own a Nitropad ns70
Firmware: Dasharo Nitrokey-v2.5.0
USB ToKey: NK3A I am worried about an issue I just became aware of:
Since my Nitropad model is 12th gen. Alderlake architecture, I am concerned that this flaw might be present with the current version of Dasharo/Heads I use (v2.5.0, but I am not aware of any newer version of the firmware for this laptop)
So my question is this: has the above mentioned issue been addressed yet or should I be aware that I lack proper IOMMU configuration early in the boot process in order to twart DMA attacks? EDIT: this here https://review.coreboot.org/c/coreboot/+/68450 seems to indicate that the issue was solved for Alderlake at least. (but it is kind of old, March 2023)
Does the current v2.5.0 firmware actually include this fix?
I’d be surprised, if the fix is included already (see the issue you link in your first post). I think you can test it by booting into the heads recovery console menu option, then try cbmem -1 | grep -e DMA and see whether it produces anything related. However, consider heads is designed to protect itself from exactly this kind of attack. Still, it’s a valid point, since heads cannot enforce protection against a malicious firmware being flashed to the storage device itself. Maybe some users may want to be able to measure integrity of such firmware, i.e. ensure it did not change while the machine was powered off.
Thank you for your reply and advice.
I am not currently writing this on my Nitropad, so I cannot try your cbmem log suggestion. I will do this later on and report.
I don’t understand this statement - we are really talking about coreboot here, not the payload itself. My understanding is that coreboot should set up DMA remapping engines as early as possible in order to disable rogue DMA transactions from PCI. I agree that such attack would be quite difficult to achieve (perhaps through the card reader or thunderbolt?) without internal access to the MBD. And if a physical attack with enough time, it would probably be much easier to simply reflash the SPI flash ROM with a programmer rather than meddling with PCI attached daughterboards.
It’s not clear to me if you are talking about the flash ROM or the internal SSD here.
Yes indeed! Do you know of any way to do this without having to take apart the machine and read the flash content to prove it is good? Cumbersome…
Or maybe something like Flashkeeper NLnet; Flashkeeper - very promising, but we don’t have that yet.
I was referring to SSD/storage device firmware, not the MB flash ROM - while that can be flashed maliciously, the heads OTP second factors are supposed to catch it during the measured boot. Have a look at
and you’ll see coreboot forms a part of the measured boot. If parts of the ROM are/would be susceptible to be flashed without triggering it, why would an attacker use a rogue PCI device (re exploit the DMA issue) instead to just booting the machine and flash from the heads menu?
Following that reasoning, I arrived at that PCI device firmware could be manipulated with such an attack. But I think this leads us off track regarding the dma issue you refer to at this point.
