linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Tony Luck <tony.luck@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Dave Hansen <dave.hansen@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Subject: Re: [RFC PATCH 1/4] x86/sgx: Track phase and type of SGX EPC pages
Date: Tue, 13 Jul 2021 16:56:24 +0000	[thread overview]
Message-ID: <YO3FuBupQTKYaKBf@google.com> (raw)
In-Reply-To: <20210608214038.1026259-2-tony.luck@intel.com>

On Tue, Jun 08, 2021, Tony Luck wrote:
> Add a type field to struct epc_page for how an in-use page has been
> allocated. Re-use "enum sgx_page_type" for this type, with a couple
> of additions for s/w types.

IMO, taking different actions based on the page type is flawed.  Ditto for adding
a flag to track so called "dirty" pages.

> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index 3be203297988..abf6e1a704c0 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -72,7 +72,7 @@ static struct sgx_epc_page *sgx_encl_eldu(struct sgx_encl_page *encl_page,
>  	struct sgx_epc_page *epc_page;
>  	int ret;
>  
> -	epc_page = sgx_alloc_epc_page(encl_page, false);
> +	epc_page = sgx_alloc_epc_page(encl_page, SGX_PAGE_TYPE_REG, false);

This is wrong when reloading an SECS page.

>  	if (IS_ERR(epc_page))
>  		return epc_page;
>  
> @@ -651,7 +667,8 @@ static bool __init sgx_setup_epc_section(u64 phys_addr, u64 size,
>  
>  	for (i = 0; i < nr_pages; i++) {
>  		section->pages[i].section = index;
> -		section->pages[i].flags = 0;
> +		section->pages[i].flags = SGX_EPC_PAGE_DIRTY;

This flag is confusing, "dirty" in paging context almost always refers to the
page having been written.  The existing sgx_dirty_page_list name is not good,
fixing that instead of propagating the bad name would preferable.

But why is the flag needed?  If the flag is set iff the page is on the dirty
list, what's the point of the flag?

Looking forward to patch 3, why does sgx_memory_failure() need to eagerly remove
pages from the list?  Just have the sanitization skip poisoned pages.

> +		section->pages[i].type = SGX_PAGE_TYPE_FREE;
>  		section->pages[i].owner = NULL;
>  		list_add_tail(&section->pages[i].list, &sgx_dirty_page_list);
>  	}

  reply	other threads:[~2021-07-13 16:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 21:40 [RFC PATCH 0/4] Machine check recovery for SGX Tony Luck
2021-06-08 21:40 ` [RFC PATCH 1/4] x86/sgx: Track phase and type of SGX EPC pages Tony Luck
2021-07-13 16:56   ` Sean Christopherson [this message]
2021-07-27  1:48     ` Sakkinen, Jarkko
2021-06-08 21:40 ` [RFC PATCH 2/4] x86/sgx: Add basic infrastructure to recover from errors in SGX memory Tony Luck
2021-07-13 17:14   ` Sean Christopherson
2021-06-08 21:40 ` [RFC PATCH 3/4] x86/sgx: Hook sgx_memory_failure() into mainline code Tony Luck
2021-06-08 21:40 ` [RFC PATCH 4/4] x86/sgx: Add hook to error injection address validation Tony Luck

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=YO3FuBupQTKYaKBf@google.com \
    --to=seanjc@google.com \
    --cc=dave.hansen@intel.com \
    --cc=jarkko.sakkinen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.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).