Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fe896ec7-cfce-e8ce-240d-88cca47f8996@intel.com>
Date:   Mon, 27 Jun 2022 11:24:33 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH v8 4/5] x86/mm: Add noalias variants of
 set_memory_*crypted() functions
Content-Language: en-US
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H . Peter Anvin" <hpa@zytor.com>, Tony Luck <tony.luck@intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Kai Huang <kai.huang@intel.com>,
        Wander Lairson Costa <wander@redhat.com>,
        Isaku Yamahata <isaku.yamahata@gmail.com>,
        marcelo.cerri@canonical.com, tim.gardner@canonical.com,
        khalid.elmously@canonical.com, philip.cox@canonical.com,
        linux-kernel@vger.kernel.org
References: <20220609025220.2615197-1-sathyanarayanan.kuppuswamy@linux.intel.com>
 <20220609025220.2615197-5-sathyanarayanan.kuppuswamy@linux.intel.com>
 <b4190b5d-89e8-b02f-5ef6-c05047af8166@intel.com>
 <20220627151257.fhynhvcnpk22kflw@black.fi.intel.com>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <20220627151257.fhynhvcnpk22kflw@black.fi.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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".