From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
dave.hansen@linux.intel.com, x86@kernel.org,
yang.zhong@intel.com, jarkko@kernel.org, bp@suse.de
Subject: Re: [PATCH v3 2/2] x86: sgx_vepc: implement SGX_IOC_VEPC_REMOVE ioctl
Date: Mon, 18 Oct 2021 17:17:30 +0000 [thread overview]
Message-ID: <YW2sKq1pXkuiG1rb@google.com> (raw)
In-Reply-To: <20211016071434.167591-3-pbonzini@redhat.com>
> +static long sgx_vepc_remove_all(struct sgx_vepc *vepc)
> +{
> + struct sgx_epc_page *entry;
> + unsigned long index;
> + long failures = 0;
> +
> + xa_for_each(&vepc->page_array, index, entry) {
> + int ret = sgx_vepc_remove_page(entry);
> + if (ret) {
> + if (ret == SGX_CHILD_PRESENT) {
There's a ton of documentation in the changelog and official docs, but a comment
here would also be helpful.
> + failures++;
> + } else {
> + /*
> + * Unlike in sgx_vepc_free_page, userspace might
> + * call the ioctl while logical processors are
> + * running in the enclave, or cause faults due
> + * to concurrent access to pages under the same
> + * SECS. So we cannot warn, we just report it.
Technically the kernel can WARN on #PF[*], as EREMOVE only hits #PF if there's a
legitimate #PF or if the target page is not an EPC page. FWIW, the comments are
a little less compressed if the if statements aren't nested.
if (ret == SGX_CHILD_PRESENT) {
/*
* Track and return the number of SECS pages that cannot
* be removed because they have child EPC pages (in this
* vEPC or a different vEPC).
*/
failures++;
} else if (ret) {
/*
* Report errors due to #GP or SGX_ENCLAVE_ACT, but do
* not WARN as userspace can induce said failures by
* calling the ioctl concurrently on multiple vEPCs or
* while one or more CPUs is running the enclave. Only
* a #PF on EREMOVE indicates a kernel/hardware issue.
*/
WARN_ON_ONCE(encls_faulted(ret) &&
ENCLS_TRAPNR(ret) == X86_TRAP_PF);
return -EBUSY;
}
[*] SGX1 hardware has an erratum where it signals #GP instead of #PF, but that's
ok in this case because it's a false negative, not a false positive.
> + */
> + return -EBUSY;
> + }
> + }
> + cond_resched();
> + }
> +
> + /*
> + * Return the number of pages that failed to be removed, so
> + * userspace knows that there are still SECS pages lying
> + * around.
Nit, the comment doesn't need to span three lines.
/*
* Return the number of pages that failed to be removed, so userspace
* knows that there are still SECS pages lying around.
*/
> + */
> + return failures;
> +}
next prev parent reply other threads:[~2021-10-18 17:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-16 7:14 [PATCH v3 0/2] x86: sgx_vepc: implement ioctl to EREMOVE all pages Paolo Bonzini
2021-10-16 7:14 ` [PATCH v3 1/2] x86: sgx_vepc: extract sgx_vepc_remove_page Paolo Bonzini
2021-10-16 7:14 ` [PATCH v3 2/2] x86: sgx_vepc: implement SGX_IOC_VEPC_REMOVE ioctl Paolo Bonzini
2021-10-18 17:17 ` Sean Christopherson [this message]
2021-10-18 17:45 ` Paolo Bonzini
2021-10-18 17:47 ` Sean Christopherson
2021-10-18 12:51 ` [PATCH v3 0/2] x86: sgx_vepc: implement ioctl to EREMOVE all pages Jarkko Sakkinen
2021-10-18 13:03 ` Paolo Bonzini
2021-10-18 13:28 ` Jarkko Sakkinen
2021-10-18 12:58 ` Borislav Petkov
2021-10-19 10:17 ` Yang Zhong
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=YW2sKq1pXkuiG1rb@google.com \
--to=seanjc@google.com \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=jarkko@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=x86@kernel.org \
--cc=yang.zhong@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 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.