On Thu, May 28, 2020 at 04:23:19AM +0300, Jarkko Sakkinen wrote: > On Wed, May 27, 2020 at 10:46:38PM +0200, Borislav Petkov wrote: > > On Tue, May 26, 2020 at 09:21:11PM -0700, Sean Christopherson wrote: > > > In other words, sgx_alloc_epc_section() is poorly named. It doesn't > > > actually allocate EPC, it allocates kernel structures to map and track EPC. > > > sgx_(un)map_epc_section() would be more accurate and would hopefully > > > alleviate some of the confusion. ... > I'm not sure I follow fully Sean's reasoning but the way alloc is used > mostly in Linux is to ask through some API the used kernel memory > allocator to give memory for some kernel data structures. Function names are usually some form of <namespace>_<verb>_<object> where 'object' is the target of the 'verb'. So sgx_alloc_epc_section() is most likely going to be read as "SGX, allocate an EPC section". But that code doesn't allocate an EPC section, it maps an EPC section, and on success, adds the section's pages to the unsanitized list, i.e. what effectively becomes the pool of EPC pages. The allocation part is a side effect of how we track EPC pages, it's not the primary purpose of the function. Maybe sgx_add_epc_section() and sgx_remove_epc_section() would be better than map/unmap? Eliminating the misnamed sgx_alloc_epc_section() frees up the "alloc" verb for use in the actual EPC page allocation paths, i.e. avoids having to rename those to "grab". IMO, "alloc" is the best name as it most closely aligns with the nomenclature for regular pages, e.g. "grab" is most often used to elevate refcounts.
