linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
	dave.hansen@linux.intel.com, jarkko@kernel.org,
	linux-sgx@vger.kernel.org
Cc: haitao.huang@intel.com
Subject: Re: [RFC PATCH 0/4] SGX shmem backing store issue
Date: Fri, 29 Apr 2022 12:45:37 -0700	[thread overview]
Message-ID: <faaaf70d-22b7-eaa5-4623-bbdf1012827a@intel.com> (raw)
In-Reply-To: <825cee74-6581-1f3b-0a64-9480d6d4a8b8@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On 4/29/22 11:50, Reinette Chatre wrote:
> I am not familiar with this area - is the PFN expected to be consistent? Do
> you perhaps have an idea why the PFN of the PCMD page may have changed? This
> is running with this series applied so the ELDU flow would do a lookup of the
> PCMD page and not attempt to allocate a new one.

First of all, cool!  This is really good progress!

It's possible for the PCMD shmem page to be swapped out and swapped back
in.  The pfn would be likely to change in that case.  But, that seems
highly unlikely in that short of a period of time.

I'd dump out two more things:

First, dump out page_pcmd_off, just like you're doing with page_index in
case page_pcmd_off itself is getting botched.  I looked but couldn't
find anything obvious.

Second, dump out the pfn in sgx_encl_truncate_backing_page().  It's
possible that something is getting overly-aggressive and zapping the
PCMD page too early.  That would be easy to explain with that PCMD
locking issue you discovered.  But, your patch should have fixed that issue.

For debugging, could you double-check that the PCMD page *is* empty
around sgx_encl_truncate_backing_page()?  If there's a race here you can
also enlarge the race window by adding an msleep() or a spin loop
somewhere after the memchr_inv().

You could also hold an extra reference on the PCMD page, maybe something
like the attached patch.  That will let you inspect the actual page
after it is *actually* truncated.  There should never be data in the
page there.

[-- Attachment #2: pcmd.diff --]
[-- Type: text/x-patch, Size: 773 bytes --]

diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 7c63a1911fae..309ffae43e0f 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -91,15 +91,20 @@ static int __sgx_encl_eldu(struct sgx_encl_page *encl_page,
 	 */
 	pcmd_page_empty = !memchr_inv(pcmd_page, 0, PAGE_SIZE);
 
-	kunmap_atomic(pcmd_page);
 	kunmap_atomic((void *)(unsigned long)pginfo.contents);
 
+	get_page(b.pcmd);
 	sgx_encl_put_backing(&b, false);
 
 	sgx_encl_truncate_backing_page(encl, page_index);
 
-	if (pcmd_page_empty)
+	if (pcmd_page_empty) {
 		sgx_encl_truncate_backing_page(encl, PFN_DOWN(page_pcmd_off));
+		WARN_ON(memchr_inv(pcmd_page, 0, PAGE_SIZE);
+	}
+
+	kunmap_atomic(pcmd_page);
+	put_page(pcmd_page);
 
 	return ret;
 }

  reply	other threads:[~2022-04-29 19:45 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 20:11 [RFC PATCH 0/4] SGX shmem backing store issue Reinette Chatre
2022-04-28 20:11 ` [RFC PATCH 1/4] x86/sgx: Do not free backing memory on ENCLS[ELDU] failure Reinette Chatre
2022-04-28 21:30   ` Dave Hansen
2022-04-28 22:20     ` Reinette Chatre
2022-04-28 22:53       ` Dave Hansen
2022-04-28 23:49         ` Reinette Chatre
2022-05-03  2:01           ` Kai Huang
2022-05-07 17:25           ` Jarkko Sakkinen
2022-05-09 17:17             ` Reinette Chatre
2022-05-10  0:36               ` Kai Huang
2022-05-11 10:26                 ` Jarkko Sakkinen
2022-05-11 18:29                   ` Haitao Huang
2022-05-11 22:00                     ` Kai Huang
2022-05-12 21:14                     ` Jarkko Sakkinen
2022-05-06 22:09     ` Jarkko Sakkinen
2022-04-28 20:11 ` [RFC PATCH 2/4] x86/sgx: Set dirty bit after modifying page contents Reinette Chatre
2022-04-28 21:40   ` Dave Hansen
2022-04-28 22:41     ` Reinette Chatre
2022-05-06 22:27   ` Jarkko Sakkinen
2022-05-06 22:40     ` Reinette Chatre
2022-05-07 18:01       ` Jarkko Sakkinen
2022-04-28 20:11 ` [RFC PATCH 3/4] x86/sgx: Obtain backing storage page with enclave mutex held Reinette Chatre
2022-04-28 21:58   ` Dave Hansen
2022-04-28 22:44     ` Reinette Chatre
2022-05-06 22:43   ` Jarkko Sakkinen
2022-04-28 20:11 ` [RFC PATCH 4/4] x86/sgx: Do not allocate backing pages when loading from backing store Reinette Chatre
2022-04-28 21:12 ` [RFC PATCH 0/4] SGX shmem backing store issue Dave Hansen
2022-04-29 18:50   ` Reinette Chatre
2022-04-29 19:45     ` Dave Hansen [this message]
2022-04-30  3:22       ` Reinette Chatre
2022-04-30 15:52         ` Reinette Chatre
2022-05-02 14:36         ` Dave Hansen
2022-05-02 17:11           ` Reinette Chatre
2022-05-02 21:33             ` Dave Hansen
2022-05-04 22:13               ` Reinette Chatre
2022-05-04 22:58                 ` Dave Hansen
2022-05-04 23:36                   ` Reinette Chatre
2022-05-04 23:50                     ` Dave Hansen
2022-05-05  0:08                       ` Reinette Chatre
2022-05-04 23:05                 ` Dave Hansen
2022-05-07 17:46               ` Jarkko Sakkinen
2022-05-07 17:48                 ` Jarkko Sakkinen
2022-05-09 17:09                   ` Reinette Chatre
2022-05-10 22:28                     ` Jarkko Sakkinen
2022-05-11 17:23                       ` Reinette Chatre
2022-05-12 14:10                         ` Jarkko Sakkinen
2022-04-28 21:29 ` Dave Hansen
2022-04-28 22:20   ` Reinette Chatre
2022-05-04  6:40 ` Jarkko Sakkinen
2022-05-05  6:09 ` Jarkko Sakkinen

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=faaaf70d-22b7-eaa5-4623-bbdf1012827a@intel.com \
    --to=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko@kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=reinette.chatre@intel.com \
    /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).