[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1528729329.9779.28.camel@intel.com>
Date: Mon, 11 Jun 2018 08:02:09 -0700
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: Dave Hansen <dave.hansen@...el.com>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
x86@...nel.org, platform-driver-x86@...r.kernel.org
Cc: nhorman@...hat.com, npmccallum@...hat.com,
Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>,
"open list:INTEL SGX" <intel-sgx-kernel-dev@...ts.01.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v11 11/13] intel_sgx: ptrace() support
On Fri, 2018-06-08 at 11:34 -0700, Dave Hansen wrote:
> On 06/08/2018 10:09 AM, Jarkko Sakkinen wrote:
> >
> > + ret = sgx_edbgrd(encl, entry, align, data);
> > + if (ret)
> > + break;
> > + if (write) {
> > + memcpy(data + offset, buf + i, cnt);
> > + ret = sgx_edbgwr(encl, entry, align, data);
> > + if (ret)
> > + break;
> > + }
> > + else
> > + memcpy(buf + i,data + offset, cnt);
> > + }
> The SGX instructions like "edbgrd" be great to put on a license plat,
> but we can do better in the kernel. Can you give these reasonable
> english names, please? sgx_debug_write(), maybe?
IMO the function names for ENCLS leafs are appropriate. The real
issue is the lack of documentation of the ENCLS helpers and their
naming conventions.
The sgx_<leaf> functions, e.g. sgx_edbgrd(), are essentially direct
invocations of the specific leaf, i.e. they are dumb wrappers to
the lower level leaf functions, e.g. __edbgrd(). The wrappers exist
primarily to deal with the boilerplate necessary to access a page in
the EPC. sgx_<leaf> conveys that the function contains the preamble
and/or postamble needed to execute its leaf, but otherwise does not
contain any logic.
Functions with actual logic do have English names, e.g.
sgx_encl_init(), sgx_encl_add_page(), sgx_encl_modify_pages() etc...
> Note that we have plenty of incomprehensible instruction names in the
> kernel like "wrpkru", but we do our best to keep them as confined as
> possible and make sure they don't hurt code readability.
Powered by blists - more mailing lists