Re: [PATCH v8 4/5] x86/mm: Add noalias variants of set_memory_*crypted() functions

[Dave Hansen]

On 6/27/22 08:12, Kirill A. Shutemov wrote:
> It made me thing about my recent story with load_unaligned_zeropad(). 
> If we leave the page in direct mapping mapped as private and
> load_unaligned_zeropad() will roll off to it, we will get SEPT violation
> that will terminate the TD as it is considered unaccepted.
> 
> I think we must keep aliases in think. And vmap() doesn't make much sense
> in this case :/
> 
> I urge you folks to consider DMA API again. Or have any other way to tap
> into swiotlb pool.

Ugh.  This is a good point.  We need *PHYSICAL* pages to pad the front
of any page we use for the quotes.  That means some crazy code like:

	struct page *pages[nr_pages];
	struct page *pages_vmap[nr_pages];

	for (i = 0; i < nr_pages; i++) {
		// allocate an extra "padding" page:
		pages[i] = alloc_pages(1, GFP_WHATEVER);
				       ^ note the order=1
		// record the page that will be vmap()'d:
		pages_vmap[i] = pages[i]+1;
		set_pages_decrypted(page_to_virt(pages_vmap[i]));
	}

	vmap(pages_vmap, nr_pages);

That's just adorable.  The other way is to do alloc_pages_exact() with
*one* extra page and just use contiguous memory for it.

I still don't like the idea of using the DMA API itself.  But, maybe we
need some common infrastructure that the DMA API and this code use which
says, "get me some pages that I can safely make shared".