[<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
 
