Anyone heard performance numbers on the encrypted memory? Any change in latency/bandwidth?
Would this help protect against malicious thumbdrives stealing keys out of memory? Seems like encryption would disable all DMA.
Would this help protect against malicious thumbdrives stealing keys out of memory? Seems like encryption would disable all DMA.
That's why encryption is enabled through page table bits: Of course you keep the pages unencrypted in which you do DMA. But you're right, a hostile DMA-capable device (eg. thunderbolt, firewire, pci-e) can only read/write garbage to those pages.
But since they can still write there (even if it's gibberish once decrypted), IOMMU remains the better solution to protect memory from hostile devices.
So I see a number of possibilities here:
1. USB controller will have DMA enabled, but you'll get back unencrypted memory from the memory region allocated to the OS that initialized the USB controller (i.e. all your RAM if you only run one OS)
2. USB controller will have DMA enabled, but you'll get back encrypted data from memory (I think this is less likely)
3. DMA must be explicitly enabled by the OS, so until that occurs DMA will remain disabled.
The anandtech article does mention that OS modifications are necessary unless the encryption operated in Transparent mode (a setting in UEFI). In Transparent mode I would assume any DMA attacks which work today would continue to function since the behaviour of the platform is identical to previous processors.
Disclaimer: armchair speculation
That makes sense, DMA must be possible in transparent mode or otherwise nothing would work. Which also means there must be physical possibility for PCI devices to use the encryption engine.
However, I suspect that the only key ever available to PCI devices is the key of the host OS (if transparent mode is enabled) and encrypted guests can't use DMA to passed-through devices at all. Otherwise, the host could try to program a passed-through device while the guest isn't executing at the moment and mess with the guest's memory using DMA. If that's true, a simple solution to hide from DMA attacks is running inside an encrypted VM, assuming that they really got the design and implementation of this feature right.
If a device did manage to escape the confines of the IOMMU somehow, then it would likely just get the encrypted pages, which would be garbage without the keys to decrypt them.
This SE post says something about DMA in USB 3.1, but I couldn't quickly find any confirmation that something has changed in version 3.1 in that regard. I didn't follow this standard closely, though.
However, 3.x controllers usually run firmware blobs of unknown quality and if a device manages to pwn this firmware then it may turn out to be able to access other memory. I think that's what the poster was worried about.
I don't think it's possible to "disable USB DMA". At least in case of 1.x/2.0 controllers most of the communication between OS and controller happens through RAM data structures and nothing would work without DMA.
The right solution is of course IOMMU.
Nothing has changed with regard to DMA. What _has_ changed is the introduction of the "Streams" feature which allows the host to establish multiple buffers in advance and have the device choose which of these to write into.
That's useful for asynchronous task delivery, eg on storage (which is AFAIK the only major use case of the feature so far): The host requests 10 transfers, prepares a properly sized buffer for each of them, and the device can fulfill them in whatever order is fastest, directly into the buffer that the OS considers the most useful for the job.
In principle, read()s from USB devices could be mapped directly into the reading process' memory space (in practice that won't happen), without the driver having to copy data around (just some signal when the data arrived and the buffer is valid).
What memory gets written to (and how much of at each address) is still managed by the host controller driver.
This feature should be safe in principle, although it does seem to increase HC attack surface a bit ;)
One more thing about 3.1 is that it can share physical ports with Thunderbolt. In such case, an innocent-looking USB gadget may turn out to do interesting things.
The HC attack surface is already significantly increased because XHCI does many things on its own that used to be done in the driver (eg. the whole address assigning handshake).
XHCI is the first USB controller variant that a USB device project I worked on was able to lock up the controller so hard it took a cold reboot of the computer to fix. That was... unexpected.
(and I can't say I'm happy about that type of complexity ending up in places where I can't fix them)
Famous last words. :-)
One important factor missing from this article is the AES cipher mode being used. Not sure how you'd be able to use an authenticated mode and maintain random access, so maybe XTS or even ECB?
Short of finding some sort of silicon backdoor, you can't get at it.
For SEV (VM encryption), I believe the keys are managed by the hypervisor.
"Secure Virtualized Encyrption (SEV). SEV in many ways resembles the SME, but in this case, it enables owners to encrypt virtual machines, isolating them from each other, hypervisors, and hosting software. "
Sounds like the keys are managed by VMs can isolated from hypervisors/hosting software.