All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.