[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200506121618.GA170146@linux.intel.com>
Date: Wed, 6 May 2020 15:16:18 +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 04:12:07PM +0200, Jethro Beekman wrote:
> On 2020-04-30 10:23, Jarkko Sakkinen wrote:
> > 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?
> >
>
> v29 patches 2 through 18:
>
> Acked-by: Jethro Beekman <jethro@...tanix.com>
>
> I only ran production SGX software. I didn't run the self test.
That's great to hear thank you.
Updated my tree accordingly.
/Jarkko
Powered by blists - more mailing lists