[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200430082328.GA6387@linux.intel.com>
Date: Thu, 30 Apr 2020 11:23:28 +0300
From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To: Jethro Beekman <jethro@...tanix.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
dave.hansen@...el.com, sean.j.christopherson@...el.com,
nhorman@...hat.com, npmccallum@...hat.com, haitao.huang@...el.com,
andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
kai.svahn@...el.com, bp@...en8.de, josh@...htriplett.org,
luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com,
cedric.xing@...el.com, puiterwijk@...hat.com
Subject: Re: [PATCH v29 00/20] Intel SGX foundations
On Thu, Apr 30, 2020 at 09:19:48AM +0200, Jethro Beekman wrote:
> On 2020-04-30 05:46, Jarkko Sakkinen wrote:
> > On Wed, Apr 29, 2020 at 05:27:48PM +0200, Jethro Beekman wrote:
> >> On 2020-04-21 23:52, Jarkko Sakkinen wrote:
> >>> Intel(R) SGX is a set of CPU instructions that can be used by applications
> >>> to set aside private regions of code and data. The code outside the enclave
> >>> is disallowed to access the memory inside the enclave by the CPU access
> >>> control.
> >>>
> >>> There is a new hardware unit in the processor called Memory Encryption
> >>> Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define
> >>> one or many MEE regions that can hold enclave data by configuring them with
> >>> PRMRR registers.
> >>>
> >>> The MEE automatically encrypts the data leaving the processor package to
> >>> the MEE regions. The data is encrypted using a random key whose life-time
> >>> is exactly one power cycle.
> >>>
> >>> The current implementation requires that the firmware sets
> >>> IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can
> >>> decide what enclaves it wants run. The implementation does not create
> >>> any bottlenecks to support read-only MSRs later on.
> >>>
> >>> You can tell if your CPU supports SGX by looking into /proc/cpuinfo:
> >>>
> >>> cat /proc/cpuinfo | grep sgx
> >>
> >> Let's merge this.
> >
> > So can I tag reviewed-by's?
> >
>
> No, but you already have my tested-by's.
>
> If it helps I can try to review some patches, but 1) I know nothing
> about kernel coding guidelines and best practices and 2) I know little
> about most kernel internals, so I won't be able to review every patch.
Ackd-by *acknowledges* that the patches work for you. I think that would
be then the correct choice for the driver patch and patches before that.
Lets go with that if that is cool for you of course.
Did you run the selftest only or possibly also some internal Fortanix
tests?
/Jarkko
Powered by blists - more mailing lists