linux-kernel - Re: [PATCH v30 08/20] x86/sgx: Add functions to allocate and free EPC pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 28 May 2020 09:52:23 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
        x86@...nel.org, linux-sgx@...r.kernel.org,
        akpm@...ux-foundation.org, dave.hansen@...el.com,
        nhorman@...hat.com, npmccallum@...hat.com, haitao.huang@...el.com,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        kai.svahn@...el.com, josh@...htriplett.org, luto@...nel.org,
        kai.huang@...el.com, rientjes@...gle.com, cedric.xing@...el.com,
        puiterwijk@...hat.com, Jethro Beekman <jethro@...tanix.com>
Subject: Re: [PATCH v30 08/20] x86/sgx: Add functions to allocate and free
 EPC pages

On Wed, May 27, 2020 at 06:36:18PM -0700, Sean Christopherson wrote:
> 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.

I'm thinking that you are over-engineering something this :-) Naming is
never perfect.

But I do get the original comment about sgx_alloc_page().

/Jarkko