Message ID | 20201003045059.665934-1-jarkko.sakkinen@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Intel SGX foundations | expand |
On Sat, Oct 03, 2020 at 07:50:35AM +0300, 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 I might be late to the game, but why are you trying to dual-license the new files you are adding in this patch? How will that help anyone? I have had many talks with Intel about this in the past, and last I heard was that when dual-licensing made sense, they would be explicit as to why it was happening. Or is my memory failing me? thanks, greg k-h
On Sat, Oct 03, 2020 at 04:32:46PM +0200, Greg KH wrote: > I might be late to the game, but why are you trying to dual-license the > new files you are adding in this patch? How will that help anyone? > > I have had many talks with Intel about this in the past, and last I > heard was that when dual-licensing made sense, they would be explicit as > to why it was happening. Or is my memory failing me? My true and honest answer is that I cannot recall. Not sure even if it was like when the driver was still out-of-tree implementation. This would back to 2016 :-) But we don't need to dig the exact answr because ➜ linux-tpmdd (next) ✔ git --no-pager grep -e BSD --and \( -e SPDX \) -- "arch/*.[Sc]" arch/arm64/lib/tishift.S:/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) Oh darn, I guess this implies that my hands are tied :-) I'll gladly implement the change. > thanks, > > greg k-h Thank you. /Jarkko
On 10/2/20 9:50 PM, Jarkko Sakkinen wrote: ... > You can tell if your CPU supports SGX by looking into /proc/cpuinfo: > > cat /proc/cpuinfo | grep sgx This is only true *after* applying this series, right?
On Thu, Oct 15, 2020 at 12:06:52PM -0700, Dave Hansen wrote: > On 10/2/20 9:50 PM, Jarkko Sakkinen wrote: > ... > > You can tell if your CPU supports SGX by looking into /proc/cpuinfo: > > > > cat /proc/cpuinfo | grep sgx > > This is only true *after* applying this series, right? Yes, that's correct. /Jarkko