Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 16 Apr 2021 16:08:11 +0300
From:   Jarkko Sakkinen <jarkko@kernel.org>
To:     Jethro Beekman <jethro@fortanix.com>
Cc:     Raoul Strackx <raoul.strackx@fortanix.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] x86/sgx: eextend ioctl
Message-ID: <YHmMO51+jI8NXwuG@kernel.org>
References: <da7ae1e7-59b8-63db-a9f1-607b4e529639@fortanix.com>
 <YHbJfXqyhtUb1AKw@kernel.org>
 <928ded49-3e86-eae0-de87-f570cf477aef@fortanix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <928ded49-3e86-eae0-de87-f570cf477aef@fortanix.com>
Precedence: bulk

On Wed, Apr 14, 2021 at 01:01:02PM +0200, Jethro Beekman wrote:
> On 2021-04-14 12:52, Jarkko Sakkinen wrote:
> > On Mon, Apr 12, 2021 at 10:59:56AM +0200, Raoul Strackx wrote:
> >> Creation of an SGX enclave consists of three steps. First, a new enclave
> >> environment is created by the ECREATE leaf function. Some enclave settings
> >> are specified at this step by passing an SGX Enclave Control Structure
> >> (SECS) that contains the enclave MRENCLAVE, MRSIGNER, etc. This
> >> instruction also starts a cryptographic log of the enclave being built.
> >> (This log should eventually result in the MRENCLAVE.) Second, pages are
> >> added to the enclave. The EADD leaf function copies 4KB data to an empty
> >> EPC page. The cryptographic log records (among other properties) the
> >> location and access rights of the page being added. It _does not_ include
> >> an entry of the page content. When the enclave writer wishes to ensure the
> >> content of (a part of) the enclave page as well, she must use the EEXTEND
> >> leaf function. Extending the enclave cryptographic log can only be done
> >> per 256 bytes. Extending the log with a full 4K page thus requires 16
> >> invocations of the EEXTEND leaf function. It is however up to the enclave
> >> developer to decide if and how enclave memory is added to the 
> >> cryptographic log. EEXTEND functions may be issued only for relevant parts
> >> of an enclave page, may happen only after all pages have been added, and
> >> so on. Finally, the enclave is finalized by the EINIT leaf function. Any
> >> new invocations of the EADD or EEXTEND leaf functions will result in a
> >> fault. With EINIT a number of checks are performed as well. The 
> >> cryptographic hash of the final cryptographic log is compared to the
> >> MRENCLAVE field of the SECS structure passed to the ECREATE leaf function
> >> (see step one). The signature (MRSIGNER) over this MRENCLAVE is verified
> >> as well. When all checks pass, the enclave loading is complete and it
> >> enters the executable state.
> > 
> > Who do you expect to read this paragraph, seriously?
> 
> What do you mean? There was a request for more architectural details in the cover letter.

So you are saying that it is well structured text and not a brain dump?

/Jarkko