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.
Checking the cbmem logs on my Nitropad (as you suggested in your first reply), I only found one line concerning DMA: ?ACPI: * DMAR
as you can see, this output happens very late in the ramstage (almost at the end) when ACPI tables are being constructed. I reviewed the entire log, but I did not find any other reference to anything DMA, IOMMU, VT-d, directed IO or such indication that iommu/VT-d was sucessfully initialized and configured…
My best guess is that CONFIG_ENABLE_EARLY_DMA_PROTECTION=y was set to n (disabled) because on both Alderlake and Meteorlake it creates problems such as: [ERROR] VT-d PMR HOB not found, not enabling DMA protection
So we can probably say that this is an unresolved issue. Will it be resolved at some point? Is there going to be a subsequent firmware update? Who knows.
I am a bit disappointed, because Dasharo/Heads and Nitrokey as well, advertise that they will maintain the firmware and provide updates addressing found bugs; and also very important: continued support and updates in the long run (contrary to IBVs and OEMs failing to do so with consumer hardware)
I agree with you on this point. DMA attacks on the boot path that would not be detected is a far-fetched concept, but it cannot be ruled out entirely. It’s just that I’m a bit disappointed that there seems to be no follow-up on firmware updates, contradictory with Nitrokey’s promises.
I agree with your testing conclusion. cbmem should have a message like “Setting DMA protection”, if it was set.
I also understand your disappointment. There have been very fast firmware updates to fix discovered bugs, but other than that the release cycle is not clear to me either.
IOMMU It is used to protect against DMA attack in Dasharo + coreboot, does this during system startup
…
On Clevo NV41 and Clevo NS50 models this is disabled, and I don’t understand why
Clevo NS50 is Nitropads NS50/NS70, which have the same firmware in common.
But anyway this seems to be more of a coreboot issue; maybe it has been addressed already but not yet integrated in downstream Dasharo - I wonder why and if Nitrokey is aware of this as well…
