Intel SGX development
 help / color / mirror / Atom feed
From: "Haitao Huang" <haitao.huang@linux.intel.com>
To: "Jarkko Sakkinen" <jarkko@kernel.org>,
	dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org,
	linux-sgx@vger.kernel.org, "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Dave Hansen" <dave.hansen@intel.com>
Cc: kai.huang@intel.com, reinette.chatre@intel.com,
	kristen@linux.intel.com, seanjc@google.com,
	stable@vger.kernel.org
Subject: Re: [PATCH] x86/sgx: fix a NULL pointer
Date: Tue, 18 Jul 2023 13:11:36 -0500	[thread overview]
Message-ID: <op.18ah5mn3wjvjmi@hhuan26-mobl.amr.corp.intel.com> (raw)
In-Reply-To: <dfb1f233-aebd-50cf-8704-e83b91ee110a@intel.com>

On Tue, 18 Jul 2023 09:27:49 -0500, Dave Hansen <dave.hansen@intel.com>  
wrote:

> On 7/17/23 13:29, Haitao Huang wrote:
>> Under heavy load, the SGX EPC reclaimers (current ksgxd or future EPC
>> cgroup worker) may reclaim the SECS EPC page for an enclave and set
>> encl->secs.epc_page to NULL. But the SECS EPC page is used for EAUG in
>> the SGX #PF handler without checking for NULL and reloading.
>>
>> Fix this by checking if SECS is loaded before EAUG and load it if it was
>> reclaimed.
>
> It would be nice to see a _bit_ more theory of the bug in here.
>
> What is an SECS page and why is it special in a reclaim context?  Why is
> this so hard to hit?  What led you to discover this issue now?  What is
> EAUG?

Let me know if this clarify things.

The SECS page holds global states of an enclave, and all reclaimable pages  
tracked by the SGX EPC reclaimer (ksgxd) are considered 'child' pages of  
the SECS page corresponding to that enclave.  The reclaimer only reclaims  
the SECS page when all its children are reclaimed. That can happen on  
system under high EPC pressure where multiple large enclaves demanding  
much more EPC page than physically available. In a rare case, the  
reclaimer may reclaim all EPC pages of an enclave and it SECS page,  
setting encl->secs.epc_page to NULL, right before the #PF handler get the  
chance to handle a #PF for that enclave. In that case, if that #PF happens  
to require kernel to invoke the EAUG instruction to add a new EPC page for  
the enclave, then a NULL pointer results as current code does not check if  
encl->secs.epc_page is NULL before using it.

The bug is easier to reproduce with the EPC cgroup implementation when a  
low EPC limit is set for a group of enclave hosting processes. Without the  
EPC cgroup it's hard to trigger the reclaimer to reclaim all child pages  
of an SECS page. And it'd also require a machine configured with large RAM  
relative to EPC so no OOM killer triggered before this happens.

Thanks
Haitao


  reply	other threads:[~2023-07-18 18:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17 18:17 [PATCH] x86/sgx: fix a NULL pointer Haitao Huang
2023-07-17 18:53 ` Jarkko Sakkinen
2023-07-17 18:54   ` Jarkko Sakkinen
2023-07-17 20:29     ` Haitao Huang
2023-07-17 22:42       ` Huang, Kai
2023-07-18  0:45         ` Haitao Huang
2023-07-18  1:39           ` Huang, Kai
2023-07-18  2:42             ` Haitao Huang
2023-07-18 14:27       ` Dave Hansen
2023-07-18 18:11         ` Haitao Huang [this message]
2023-07-18 18:53           ` Dave Hansen
2023-07-18 20:32             ` Haitao Huang
2023-07-18 20:56               ` Dave Hansen
2023-07-18 21:22                 ` Haitao Huang
2023-07-18 21:36                   ` Dave Hansen
2023-07-18 21:57                     ` Haitao Huang
2023-07-18 22:05                       ` Dave Hansen
2023-07-19  0:06                         ` Haitao Huang
2023-07-19  0:14                       ` Huang, Kai
2023-07-19  0:21                         ` Dave Hansen
2023-07-19 13:53                           ` Haitao Huang
2023-07-21  0:32                             ` Huang, Kai
2023-07-21  0:52                               ` Huang, Kai
2023-07-26 16:56                                 ` Haitao Huang
2023-07-18 14:30       ` Dave Hansen
2023-07-18 16:39         ` Haitao Huang
2023-07-18 15:37       ` Jarkko Sakkinen
2023-07-18 23:11         ` 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=op.18ah5mn3wjvjmi@hhuan26-mobl.amr.corp.intel.com \
    --to=haitao.huang@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=kai.huang@intel.com \
    --cc=kristen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=seanjc@google.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --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