6 ms·
Anyone heard performance numbers on the encrypted memory? Any change in latency/bandwidth? Would this help protect against malicious thumbdrives stealing keys
by sliken 9y ago
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.
- 0xbear 9y agoYou don't need encryption to disable USB DMA. IIRC Apple and Microsoft disable DMA in recent versions of their OS when you lock your computer. Don't know about Linux, would appreciate if someone shared the state of affairs there.
- qb45 9y agoWhat's USB DMA?
- 0xbear 9y agoDirect memory access by USB host controller. A good explanation can be found here: https://security.stackexchange.com/questions/118854/attacks-via-physical-access-to-usb-dma https://security.stackexchange.com/questions/118854/attacks-...
- qb45 9y agoOK, I see. For the record, USB devices can't simply request the host controller to read or write whatever they want, as it was the case with FireWire and Thunderbolt, which is why people say that "USB doesn't have DMA". The controller will only do DMA to/from OS-specified USB buffers. 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.
- dom0 9y agoThe same is btw. true for SATA, SCSI, SAS: the "DMA modes" (UDMA etc.) mean that the host controller is doing DMA transfers, while SATA drives cannot initiate nor control DMA transfers.
- pgeorgi 9y ago> 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. 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.
- qb45 9y ago> 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. 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.
- pgeorgi 9y agoSimple solution: don't use Intel, in which case there is no Thunderbolt controller to subvert your system.
- kogepathic 9y ago> Seems like encryption would disable all DMA. 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
- qb45 9y ago> In Transparent mode I would assume any DMA attacks which work today would continue to function 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.
- jamesfmilne 9y agoIOMMUs are designed to prevent peripherals accessing all of memory, so you don't need to disable DMA. 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.
- the8472 9y agoLinux and macos use the IOMMU for protection by default. Windows needs a lot of configuration to achieve that otherwise it only uses it for virtualization.
- pgeorgi 9y ago> 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.
- laydn 9y agoAnyone know where the AES key is stored for the encrypted memory? Is is a fixed, hardcoded key inside the processor, or does the user set it by some means?
- daxorid 9y agoSpeculation here. Since the PSP is effectively leveraging TrustZone, I'm guessing it's generated and stored inside the TrustZone itself. This article states it's generated by a hardware RNG, so user control is unlikely. 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?
- amluto 9y agoSGX does it, but it's quite complicated. SME is unauthenticated AFAIK.
- TazeTSchnitzel 9y agoFor whole-system RAM encryption (SME, i.e. not VMs), it's generated by the processor at boot time, and stored within it. 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.
- srcmap 9y agoFrom the article: "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.