Re: [PATCH] x86/sgx: Fix free_cnt counting logic in epc section

On Mon, Jan 18, 2021, Tianjia Zhang wrote:

Increase `section->free_cnt` in sgx_sanitize_section() is more reasonable, which is called in ksgxd kernel thread, instead of assigning it to epc section pages number at initialization. Although this is unlikely to fail, these pages cannot be allocated after initialization, and which need to be reset by ksgxd.

Reported-by: Jia Zhang zhang.jia@linux.alibaba.com Signed-off-by: Tianjia Zhang tianjia.zhang@linux.alibaba.com

Reviewed-by: Sean Christopherson seanjc@google.com

---

arch/x86/kernel/cpu/sgx/main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c index c519fc5f6948..9e9a3cf7c00b 100644 --- a/arch/x86/kernel/cpu/sgx/main.c +++ b/arch/x86/kernel/cpu/sgx/main.c @@ -48,9 +48,10 @@ static void sgx_sanitize_section(struct sgx_epc_section *section) struct sgx_epc_page, list); ret = __eremove(sgx_get_epc_virt_addr(page));

• if (!ret)
  

• if (!ret) {
  list_move(&page->list, &section->page_list);
  

• else
  

• 	section->free_cnt += 1;
  

• } else
  

Nit: the the "else" should also have curly braces.

	list_move_tail(&page->list, &dirty);

spin_unlock(&section->lock);

FWIW, taking section->lock could be moved inside the !ret flow so that EREMOVE is done without holding the lock. I've no idea if that'd actually change anything in practice, but it's theoretically possible that ksgxd hasn't finished sanitizing the EPC when userspace starts creating enclaves.

@@ -646,7 +647,6 @@ static bool __init sgx_setup_epc_section(u64 phys_addr, u64 size, list_add_tail(&section->pages[i].list, &section->init_laundry_list); }

• section->free_cnt = nr_pages; return true;

} -- 2.19.1.3.ge56e4f7