[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <PSAPR04MB416734EEED145D832A04B936E97B9@PSAPR04MB4167.apcprd04.prod.outlook.com>
Date: Thu, 1 Sep 2022 23:55:54 +0800
From: zhubojun <bojun.zhu@...look.com>
To: reinette.chatre@...el.com
Cc: bp@...en8.de, cathy.zhang@...el.com, cedric.xing@...el.com,
dave.hansen@...ux.intel.com, haitao.huang@...el.com, hpa@...or.com,
jarkko@...nel.org, kai.huang@...el.com,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-sgx@...r.kernel.org, luto@...nel.org,
mark.shanahan@...el.com, mingo@...hat.com, seanjc@...gle.com,
shuah@...nel.org, tglx@...utronix.de, vijay.dhanraj@...el.com,
x86@...nel.org
Subject: Re: [PATCH V5 15/31] x86/sgx: Support restricting of enclave page
permissions
Hi, Reinette, thanks for your great contribution for EDMM Linux kernel patch. I am trying to follow the newest patch now, and I have some questions on it.
It seems that `sgx_enclave_restrict_permissions()` is able to do permission restrictions for multiple enclave’s pages. After driver invokes ENCLS[EMODPR] to restrict the page’s permission, it should then invoke ENCLS[ETRACK] and send IPIs to ensure stale TLB entries have been flushed. Only in this way, ENCLU[EACCEPT] inside enclave can only succeed.
Current implementation invokes `sgx_enclave_etrack(encl)` after every `__emodpr(…)` in the for loop. My question is:
Can we move the `sgx_enclave_etrack(encl)` out of the for loop? After doing so, `sgx_enclave_etrack(encl)` is invoked **one** time for multiple enclave pages’ permission restriction, instead of N times (N = `modp -> length / PAGE_SIZE`). We may gain some performance optimization from it.
Please correct my if my understanding is incorrect. Looking forward to your reply and Thanks for your time!
BR,
Bojun
Powered by blists - more mailing lists