On 06/15/2016 08:17 AM, Tom Lendacky wrote:
On 06/13/2016 08:51 AM, Matt Fleming wrote:
quoted
On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote:
quoted
[...]
quoted
quoted
I'll look further into this, but I saw that this area of virtual memory
was mapped un-encrypted and after freeing the boot services the
mappings were somehow reused as un-encrypted for DMA which assumes
(unless using swiotlb) encrypted. This resulted in DMA data being
transferred in as encrypted and then accessed un-encrypted.
That the mappings were re-used isn't a surprise.
efi_free_boot_services() lifts the reservation that was put in place
during efi_reserve_boot_services() and releases the pages to the
kernel's memory allocators.
What is surprising is that they were marked unencrypted at all.
There's nothing special about these pages as far as the __va() region
is concerned.
Right, let me keep looking into this to see if I can pin down what
was (or is) happening.
Ok, I think this was happening before the commit to build our own
EFI page table structures:
commit 67a9108ed ("x86/efi: Build our own page table structures")
Before this commit the boot services ended up mapped into the kernel
page table entries as un-encrypted during efi_map_regions() and I needed
to change those entries back to encrypted. With your change above,
this appears to no longer be needed.
Thanks,
Tom
Thanks,
Tom
quoted
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>