linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Huang <kai.huang@intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Sathyanarayanan Kuppuswamy 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: 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>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Tony Luck <tony.luck@intel.com>, Andi Kleen <ak@linux.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
Subject: Re: [PATCH v5 3/3] x86/tdx: Add Quote generation support
Date: Fri, 06 May 2022 23:00:29 +1200	[thread overview]
Message-ID: <c3003e378504d2cd034e54bca6cab4d6bb53e008.camel@intel.com> (raw)
In-Reply-To: <d63d2774-c44d-27da-74b6-550935a196fd@intel.com>

On Thu, 2022-05-05 at 16:06 -0700, Dave Hansen wrote:
> On 5/5/22 15:15, Kai Huang wrote:
> > set_memory_xx()  is supposedly only for direct-mapping.  Please use my
> > suggestion above.
> 
> Kai, please take a look at some of the other users, especially
> set_memory_x().  See how long the "supposed" requirement holds up.
> 
> That said, I've forgotten by now if this _could_ have used vmalloc() or
> vmap() or vmap_pfn().  None of the logic about why or how the allocator
> and mapping design decisions were made.  Could that be be rectified for
> the next post?

Hi Dave,

(Sorry previous reply was too fast..)

I spent some time looking into how __change_page_attr_set_clr() is implemented,
which is called by all set_memory_xxx() variants.  If my understanding is
correct, __change_page_attr_set_clr() will work for vmap() variants, because it
internally uses lookup_address(), which walks the page table directly, to find
the actual PTE (and PFN).  So set_memory_decrypted() can be fixed to support
vmap() mapping for TDX.

However, looking at the code, set_memory_decrypted() calls
__change_page_attr_set_clr(&cpa, 1).  The second argument is 'checkalias', which
means even we call set_memory_decrypted() against vmap() address, the aliasing
mappings will be changed too.  And if I understand correctly, the aliasing
mapping includes direct-mapping too:

static int cpa_process_alias(struct cpa_data *cpa)                             
{                                                                              
        struct cpa_data alias_cpa;
        unsigned long laddr = (unsigned long)__va(cpa->pfn << PAGE_SHIFT);     
        unsigned long vaddr;
        int ret;                                                               
                                                                                                                                                   
        if (!pfn_range_is_mapped(cpa->pfn, cpa->pfn + 1))                      
                return 0;                                                      

        /*
         * No need to redo, when the primary call touched the direct           
         * mapping already:                                                    
         */
        vaddr = __cpa_addr(cpa, cpa->curpage);                                 
        if (!(within(vaddr, PAGE_OFFSET,
                    PAGE_OFFSET + (max_pfn_mapped << PAGE_SHIFT)))) {
                
                alias_cpa = *cpa; 
                alias_cpa.vaddr = &laddr;
                alias_cpa.flags &= ~(CPA_PAGES_ARRAY | CPA_ARRAY);             
                alias_cpa.curpage = 0;                                         
                
                cpa->force_flush_all = 1;                                      

                ret = __change_page_attr_set_clr(&alias_cpa, 0);               
                if (ret)                                                       
                        return ret;
        }                                                                      

#ifdef CONFIG_X86_64                                                           
        /*
         * If the primary call didn't touch the high mapping already           
         * and the physical address is inside the kernel map, we need          
         * to touch the high mapped kernel as well:
         */                                                                    
        if (!within(vaddr, (unsigned long)_text, _brk_end) &&                  
            __cpa_pfn_in_highmap(cpa->pfn)) {                                  
                unsigned long temp_cpa_vaddr = (cpa->pfn << PAGE_SHIFT) +      
                                               __START_KERNEL_map - phys_base; 
                alias_cpa = *cpa;                                              
                alias_cpa.vaddr = &temp_cpa_vaddr;                             
                alias_cpa.flags &= ~(CPA_PAGES_ARRAY | CPA_ARRAY);
                alias_cpa.curpage = 0;                                         

                cpa->force_flush_all = 1;
                /*
                 * The high mapping range is imprecise, so ignore the
                 * return value.
                 */
                __change_page_attr_set_clr(&alias_cpa, 0);
        }
#endif

        return 0;
}

As you can see, the first chunk checks whether the virtual address is direct-
mapping, and if it is not, direct mapping is changed too.

The second chunk even changes the high kernel mapping.

So, if we use set_memory_decrypted(), there's no difference whether the address
is vmap() or direct mapping address.  The direct mapping will be changed anyway.

(However, it seems if we call set_memory_decrypted() against direct mapping
address, the vmap() mapping won't be impacted, because it seems
cpa_process_alias() doesn't check vmap() area..).

However I may have missed something.  Kirill please help to confirm if you see
this.

-- 
Thanks,
-Kai



  parent reply	other threads:[~2022-05-06 11:00 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-01 18:34 [PATCH v5 0/3] Add TDX Guest Attestation support Kuppuswamy Sathyanarayanan
2022-05-01 18:34 ` [PATCH v5 1/3] x86/tdx: Add TDX Guest attestation interface driver Kuppuswamy Sathyanarayanan
2022-05-02  2:31   ` Kai Huang
2022-05-02 15:52     ` Sathyanarayanan Kuppuswamy
2022-05-02 22:30       ` Kai Huang
2022-05-02 23:17         ` Sathyanarayanan Kuppuswamy
2022-05-02 23:37           ` Kai Huang
2022-05-03 14:38           ` Wander Costa
2022-05-03 15:09             ` Sathyanarayanan Kuppuswamy
2022-05-03 22:08               ` Kai Huang
2022-05-02 12:18   ` Wander Lairson Costa
2022-05-02 16:06     ` Sathyanarayanan Kuppuswamy
2022-05-01 18:34 ` [PATCH v5 2/3] x86/tdx: Add TDX Guest event notify interrupt support Kuppuswamy Sathyanarayanan
2022-05-02 12:44   ` Wander Lairson Costa
2022-05-01 18:35 ` [PATCH v5 3/3] x86/tdx: Add Quote generation support Kuppuswamy Sathyanarayanan
2022-05-02  2:40   ` Kai Huang
2022-05-03  1:27     ` Kirill A. Shutemov
2022-05-03  2:18       ` Kai Huang
2022-05-03  2:39         ` Sathyanarayanan Kuppuswamy
2022-05-03 22:13           ` Kai Huang
2022-05-03  2:45         ` Kirill A. Shutemov
2022-05-03  3:36           ` Kai Huang
2022-05-03 22:24       ` Dave Hansen
2022-05-03 22:28         ` Sathyanarayanan Kuppuswamy
2022-05-03 22:30           ` Sathyanarayanan Kuppuswamy
2022-05-04 22:49         ` Sathyanarayanan Kuppuswamy
2022-05-04 23:28           ` Kai Huang
2022-05-05 20:53             ` Sathyanarayanan Kuppuswamy
2022-05-05 22:15               ` Kai Huang
2022-05-05 22:38                 ` Sathyanarayanan Kuppuswamy
2022-05-05 23:06                 ` Dave Hansen
2022-05-06  0:11                   ` Kai Huang
2022-05-06  1:55                     ` Sathyanarayanan Kuppuswamy
2022-05-07  0:42                     ` Kirill A. Shutemov
2022-05-09  3:37                       ` Kai Huang
2022-05-09 12:09                         ` Kirill A. Shutemov
2022-05-09 14:14                           ` Dave Hansen
2022-05-09 15:35                             ` Kirill A. Shutemov
2022-05-09 15:43                               ` Sathyanarayanan Kuppuswamy
2022-05-09 23:54                           ` Kai Huang
2022-05-10  0:17                             ` Sathyanarayanan Kuppuswamy
2022-05-10  1:30                             ` Kirill A. Shutemov
2022-05-10  1:40                               ` Kai Huang
2022-05-10 10:42                             ` Kai Huang
2022-05-16 17:39                               ` Sathyanarayanan Kuppuswamy
2022-05-06 11:00                   ` Kai Huang [this message]
2022-05-06 15:47                     ` Dave Hansen
2022-05-07  1:00                     ` Kirill A. Shutemov
2022-05-05 10:50           ` Kai Huang
2022-05-05 19:03             ` Sathyanarayanan Kuppuswamy
2022-05-05 22:25               ` Kai Huang
2022-05-02  5:01   ` Kai Huang
2022-05-02 16:02     ` Sathyanarayanan Kuppuswamy
2022-05-02 23:02       ` Kai Huang
2022-05-02 13:16   ` Wander Lairson Costa
2022-05-02 16:05     ` Sathyanarayanan Kuppuswamy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3003e378504d2cd034e54bca6cab4d6bb53e008.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@gmail.com \
    --cc=khalid.elmously@canonical.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.cerri@canonical.com \
    --cc=mingo@redhat.com \
    --cc=philip.cox@canonical.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=tim.gardner@canonical.com \
    --cc=tony.luck@intel.com \
    --cc=wander@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).