From: "Huang, Kai" <kai.huang@intel.com>
To: "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
"jarkko@kernel.org" <jarkko@kernel.org>,
"haitao.huang@linux.intel.com" <haitao.huang@linux.intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Cc: "Chatre, Reinette" <reinette.chatre@intel.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] x86/sgx: Return VM_FAULT_SIGBUS for EPC exhaustion
Date: Wed, 25 Oct 2023 23:58:29 +0000 [thread overview]
Message-ID: <b389986bac0e65ce128c9553603436efdda24a58.camel@intel.com> (raw)
In-Reply-To: <b8ec3061-436f-41d3-8bff-635a90774dfb@intel.com>
On Wed, 2023-10-25 at 07:31 -0700, Hansen, Dave wrote:
> On 10/19/23 19:53, Haitao Huang wrote:
> > In the EAUG on page fault path, VM_FAULT_OOM is returned when the
> > Enclave Page Cache (EPC) runs out. This may trigger unneeded OOM kill
> > that will not free any EPCs. Return VM_FAULT_SIGBUS instead.
>
> So, when picking an error code and we look the documentation for the
> bits, we see:
>
> > * @VM_FAULT_OOM: Out Of Memory
> > * @VM_FAULT_SIGBUS: Bad access
>
> So if anything we'll need a bit more changelog where you explain how
> running out of enclave memory is more "Bad access" than "Out Of Memory".
> Because on the surface this patch looks wrong.
>
> But that's just a naming thing. What *behavior* is bad here? With the
> old code, what happens? With the new code, what happens? Why is the
> old better than the new?
I think Haitao meant if we return OOM, the core-MM fault handler will believe
the fault couldn't be handled because of running out of memory, and then it
could invoke the OOM killer which might select an unrelated victim who might
have no EPC at all.
If we return SIGBUS, then the faulting process/enclave will get the signal and,
e.g., get killed.
static inline
void do_user_addr_fault(struct pt_regs *regs,
unsigned long error_code,
unsigned long address)
{
...
fault = handle_mm_fault(vma, address, ...);
...
done:
...
if (fault & VM_FAULT_OOM) {
/* Kernel mode? Handle exceptions or die: */
if (!user_mode(regs)) {
kernelmode_fixup_or_oops(regs, error_code, address,
SIGSEGV, SEGV_MAPERR,
ARCH_DEFAULT_PKEY);
return;
}
/*
* We ran out of memory, call the OOM killer, and return the
* userspace (which will retry the fault, or kill us if we got
* oom-killed):
*/
pagefault_out_of_memory();
} else {
if (fault & (VM_FAULT_SIGBUS|VM_FAULT_HWPOISON|
VM_FAULT_HWPOISON_LARGE))
do_sigbus(regs, error_code, address, fault);
else if (fault & VM_FAULT_SIGSEGV)
bad_area_nosemaphore(regs, error_code, address);
else
BUG();
}
}
Btw, Ingo has already queued this patch to tip/urgent:
https://lore.kernel.org/all/169778941056.3135.14169781154210769341.tip-bot2@tip-bot2/T/
(Also, currently the non-EAUG code path (ELDU) in sgx_vma_fault() also returns
SIGBUS if it fails to allocate EPC, so making EAUG code path return SIGBUS also
matches the ELDU path.)
next prev parent reply other threads:[~2023-10-25 23:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 2:53 [PATCH] x86/sgx: Return VM_FAULT_SIGBUS for EPC exhaustion Haitao Huang
2023-10-23 23:30 ` Jarkko Sakkinen
2023-10-25 14:31 ` Dave Hansen
2023-10-25 23:58 ` Huang, Kai [this message]
2023-10-26 16:01 ` Reinette Chatre
2023-10-26 16:34 ` Haitao Huang
2023-10-26 21:16 ` Huang, Kai
2023-10-28 8:24 ` Ingo Molnar
2023-10-26 21:10 ` Huang, Kai
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=b389986bac0e65ce128c9553603436efdda24a58.camel@intel.com \
--to=kai.huang@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@linux.intel.com \
--cc=jarkko@kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=stable@vger.kernel.org \
--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