All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: <dave.hansen@linux.intel.com>, <linux-sgx@vger.kernel.org>,
	<haitao.huang@intel.com>
Subject: Re: [PATCH V2 5/5] x86/sgx: Ensure no data in PCMD page after truncate
Date: Wed, 11 May 2022 11:02:58 -0700	[thread overview]
Message-ID: <9c85f01a-9f9b-1d2f-7dfd-11306d623ebe@intel.com> (raw)
In-Reply-To: <YnuRxPqhOkWOAXjk@kernel.org>

Hi Jarkko,

On 5/11/2022 3:36 AM, Jarkko Sakkinen wrote:
> On Mon, May 09, 2022 at 02:48:03PM -0700, Reinette Chatre wrote:
>> A PCMD (Paging Crypto MetaData) page contains the PCMD
>> structures of enclave pages that have been encrypted and
>> moved to the shmem backing store. When all enclave pages
>> sharing a PCMD page are loaded in the enclave, there is no
>> need for the PCMD page and it can be truncated from the
>> backing store.
>>
>> A few issues appeared around the truncation of PCMD pages. The
>> known issues have been addressed but the PCMD handling code could
>> be made more robust by loudly complaining if any new issue appears
>> in this area.
>>
>> Add a check that will complain once with a WARN if the PCMD page is not
>> actually empty after it has been truncated. There should never be data
>> in the PCMD page at this point since it is always updated with the
>> enclave mutex held.
>>
>> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
>> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
>> ---
>>  arch/x86/kernel/cpu/sgx/encl.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
>> index d1d4e8572702..af972dbad965 100644
>> --- a/arch/x86/kernel/cpu/sgx/encl.c
>> +++ b/arch/x86/kernel/cpu/sgx/encl.c
>> @@ -183,12 +183,19 @@ static int __sgx_encl_eldu(struct sgx_encl_page *encl_page,
>>  	kunmap_atomic(pcmd_page);
>>  	kunmap_atomic((void *)(unsigned long)pginfo.contents);
>>  
>> +	get_page(b.pcmd);
>>  	sgx_encl_put_backing(&b);
>>  
>>  	sgx_encl_truncate_backing_page(encl, page_index);
>>  
>> -	if (pcmd_page_empty && !pcmd_page_in_use(encl, pcmd_first_page))
>> +	if (pcmd_page_empty && !pcmd_page_in_use(encl, pcmd_first_page)) {
>>  		sgx_encl_truncate_backing_page(encl, PFN_DOWN(page_pcmd_off));
>> +		pcmd_page = kmap_atomic(b.pcmd);
>> +		WARN_ON_ONCE(memchr_inv(pcmd_page, 0, PAGE_SIZE));
> 
> Is WARN necessary, or would it make more sense to use pr_warn()?
> 

I will change it to pr_warn().

> It would give a better chance to collect information if "panic_on_warn" is
> set for the running kernel.
> 

Reinette

  reply	other threads:[~2022-05-11 18:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09 21:47 [PATCH V2 0/5] SGX shmem backing store issue Reinette Chatre
2022-05-09 21:47 ` [PATCH V2 1/5] x86/sgx: Disconnect backing page references from dirty status Reinette Chatre
2022-05-10 20:12   ` Dave Hansen
2022-05-10 23:00     ` Reinette Chatre
2022-05-09 21:48 ` [PATCH V2 2/5] x86/sgx: Mark PCMD page as dirty when modifying contents Reinette Chatre
2022-05-11 10:43   ` Jarkko Sakkinen
2022-05-11 18:01     ` Reinette Chatre
2022-05-12 14:15       ` Jarkko Sakkinen
2022-05-09 21:48 ` [PATCH V2 3/5] x86/sgx: Obtain backing storage page with enclave mutex held Reinette Chatre
2022-05-11 11:13   ` Jarkko Sakkinen
2022-05-11 18:02     ` Reinette Chatre
2022-05-12 14:14       ` Jarkko Sakkinen
2022-05-09 21:48 ` [PATCH V2 4/5] x86/sgx: Fix race between reclaimer and page fault handler Reinette Chatre
2022-05-10 21:55   ` Dave Hansen
2022-05-10 23:01     ` Reinette Chatre
2022-05-09 21:48 ` [PATCH V2 5/5] x86/sgx: Ensure no data in PCMD page after truncate Reinette Chatre
2022-05-11 10:36   ` Jarkko Sakkinen
2022-05-11 18:02     ` Reinette Chatre [this message]
2022-05-11 15:00 ` [PATCH V2 0/5] SGX shmem backing store issue Haitao Huang

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=9c85f01a-9f9b-1d2f-7dfd-11306d623ebe@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko@kernel.org \
    --cc=linux-sgx@vger.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.