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:51:04 +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 05:52:17PM -0700, Sean Christopherson 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.
> > 
> > Makes sense.
> > 
> > > I have no objection to renaming __sgx_alloc_try_alloc_page() to something
> > > like sgx_alloc_epc_page_section or whatever, but IMO using get/put will be
> > > horrendously confusing.
> > 
> > Ok. My only issue is that the naming nomenclature sounds strange and
> > confusing as it is. "try" in an "alloc" function is kinda tautological -
> > of course the function will try to do its best. :)
> 
> Heh, so what you're saying is we should add __sgx_really_try_alloc_page()?
> 
> > And there are three functions having "alloc" in the name so I can
> > imagine someone getting very confused when having to stare at that code.
> > 
> > So at least naming them in a way so that it is clear what kind of pages
> > they "allocate" - i.e., what they actually do - would be a step in the
> > right direction...
> 
> Ya, and things will only get more confusing when actual NUMA awareness gets
> thrown into the mix.
> 
> Jarkko, splicing in the NUMA awareness code, what do you think about:
> 
>   sgx_alloc_epc_section -> sgx_map_epc_section
>   sgx_free_epc_section  -> sgx_unmap_epc_section

Here alloc makes sense because memory gets allocated for the data
structures.

>   sgx_alloc_page        -> sgx_alloc_epc_page
>   sgx_free_page         -> sgx_free_epc_page
> 
>   sgx_try_alloc_page    -> sgx_alloc_epc_page_node
>   __sgx_try_alloc_page  -> sgx_alloc_epc_page_section

I'm going with sgx_grab_page() and sgx_try_grab_page().

/Jarkko