-off-by: Suresh Siddha
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/uapi/asm/sgx.h | 30
arch/x86/kernel/cpu/sgx/ioctl.c | 299
arch/x86/kernel/cpu/sgx/sgx.h | 1 +
3 files changed, 330 insertions(+)
diff --git a/arch/x86/include/uapi/asm/sgx.h b
ioctl called
SGX_IOC_ENCLAVE_PROVISION is used to assign this token to an enclave.
Cc: linux-security-mod...@vger.kernel.org
Acked-by: Jethro Beekman
Reviewed-by: Darren Kenny
Suggested-by: Andy Lutomirski
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/uapi/asm/sgx.h | 11
arch
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/driver.c | 1 +
arch/x86/kernel/cpu/sgx/encl.c | 344 +-
arch/x86/kernel/cpu/sgx/encl.h | 41 +++
arch/x86/kernel/cpu/sgx/ioctl.c | 78 -
arch/x86/kernel/cpu/sgx/main.c
Christopherson
Signed-off-by: Jarkko Sakkinen
---
arch/x86/mm/fault.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 90ee91c244c6..24ab833ede41 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski
Acked-by: Jethro Beekman
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/traps.c | 10 ++
arch/x86/mm/fault.c | 7 +++
2 files changed, 17
pler than adding
the necessary infrastructure to generate pre-compiled assembly and the
intended benefit of massaging GCC's inlining algorithm is unlikely to
realized in the vDSO any time soon, if ever.
Suggested-by: Andy Lutomirski
Acked-by: Jethro Beekman
Signed-off-by: Sean Christopherson
aforementioned leaf instructions to
provide read and write primitives for the enclave memory.
Cc: linux...@kvack.org
Cc: Andrew Morton
Cc: Matthew Wilcox
Acked-by: Jethro Beekman
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/encl.c | 89 ++
1 file changed
Document the Intel SGX kernel architecture. The fine-grained micro
architecture details can be looked up from Intel SDM Volume 3D.
Cc: linux-...@vger.kernel.org
Acked-by: Randy Dunlap
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
Add a selftest for SGX. It is a trivial test where a simple enclave
copies one 64-bit word of memory between two memory locations.
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Jarkko Sakkinen
---
tools/testing/selftests/Makefile | 1 +
tools/testing
Add the maintainer information for the SGX subsystem.
Cc: Thomas Gleixner
Cc: Borislav Petkov
Signed-off-by: Jarkko Sakkinen
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b81aad6f7f97..ca1995b1ef45 100644
--- a/MAINTAINERS
ck.org
Cc: Andrew Morton
Cc: Matthew Wilcox
Acked-by: Jethro Beekman
Reviewed-by: Darren Kenny
Signed-off-by: Sean Christopherson
Co-developed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
---
include/linux/mm.h | 3 +++
mm/mprotect.c | 5 -
2 files changed, 7 insertions
-by: Nathaniel McCallum
Tested-by: Seth Moore
Tested-by: Darren Kenny
Reviewed-by: Darren Kenny
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Co-developed-by: Suresh Siddha
Signed-off-by: Suresh Siddha
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/uapi/asm
Add kernel parameter to disable Intel SGX kernel support.
Tested-by: Sean Christopherson
Reviewed-by: Sean Christopherson
Reviewed-by: Darren Kenny
Signed-off-by: Jarkko Sakkinen
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/kernel/cpu/feat_ctl.c | 9
Tested-by: Jordan Hand
Tested-by: Nathaniel McCallum
Tested-by: Seth Moore
Tested-by: Darren Kenny
Reviewed-by: Darren Kenny
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Co-developed-by: Suresh Siddha
Signed-off-by: Suresh Siddha
Signed-off-by: Jarkko Sakkinen
-developed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/asm/cpufeature.h| 5 +++--
arch/x86/include/asm/cpufeatures.h | 7 ++-
arch/x86/include/asm/disabled-features.h | 18 +++---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86
.
ENCLS leaf functions are documented in
Intel SDM: 36.6 ENCLAVE INSTRUCTIONS AND INTEL®
Acked-by: Jethro Beekman
Tested-by: Darren Kenny
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/encls.h | 238
state (i.e. not required from caller part).
Acked-by: Jethro Beekman
Reviewed-by: Darren Kenny
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/main.c | 62 ++
arch/x86/kernel
at it provides stub
implementations when sgx in not enabled.
* Removed cruft rdmsr-calls from sgx_set_pubkeyhash_msrs().
* return -ENOMEM in sgx_alloc_page() when VA pages consume too much space
* removed unused global sgx_nr_pids
* moved sgx_encl_release to sgx_encl.c
* return -ERESTARTSYS instead of -EINTR
Beekman
Reviewed-by: Darren Kenny
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/arch.h | 341 +
1 file changed, 341 insertions(+)
create mode 100644 arch/x86/kernel/cpu/sgx/arch.h
diff --git a/arch/x86/kernel/cpu/sgx/arch.h b/arch/x86/kernel/cpu/sgx
decisions from the kernel.
[1] Intel SDM: 38.1.4 Intel SGX Launch Control Configuration
Reviewed-by: Borislav Petkov
Acked-by: Jethro Beekman
Reviewed-by: Darren Kenny
Signed-off-by: Sean Christopherson
Co-developed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include
subsystem doesn't need to manually do support
checks on a per-CPU basis.
Acked-by: Jethro Beekman
Reviewed-by: Darren Kenny
Signed-off-by: Sean Christopherson
Co-developed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/feat_ctl.c | 32
-by: Sean Christopherson
Co-developed-by: Suresh Siddha
Signed-off-by: Suresh Siddha
Signed-off-by: Jarkko Sakkinen
---
arch/x86/kernel/cpu/sgx/Makefile | 2 +
arch/x86/kernel/cpu/sgx/driver.c | 173
arch/x86/kernel/cpu/sgx/driver.h | 29 +++
arch/x86/kernel/cpu/sgx/encl.c | 331
Reviewed-by: Borislav Petkov
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/asm/trap_pf.h | 1 +
arch/x86/mm/fault.c| 13 +
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/trap_pf.h b/arch/x86/include/asm/trap_pf.h
-developed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
---
arch/x86/Kconfig | 17 +++
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/sgx/Makefile | 2 +
arch/x86/kernel/cpu/sgx/main.c | 216 +++
arch/x86/kernel/cpu/sgx/sgx.h
On Fri, Oct 02, 2020 at 07:23:55PM -0500, Haitao Huang wrote:
> On Tue, 15 Sep 2020 06:28:30 -0500, Jarkko Sakkinen
> wrote:
>
> > Add an ioctl that performs ENCLS[ECREATE], which creates SGX Enclave
> > Control Structure for the enclave. SECS contains attributes
On Thu, Oct 01, 2020 at 10:36:53AM -0700, Sean Christopherson wrote:
> On Tue, Sep 15, 2020 at 02:28:29PM +0300, Jarkko Sakkinen wrote:
> > +int __init sgx_drv_init(void)
> > +{
> > + unsigned int eax, ebx, ecx, edx;
> > + u64 attr_mask, xfrm_mask;
>
On Wed, Sep 30, 2020 at 03:15:10PM -0600, Eric Snowberg wrote:
>
> > On Sep 30, 2020, at 3:02 PM, Jarkko Sakkinen
> > wrote:
> >
> > On Wed, Sep 30, 2020 at 04:15:07PM -0400, Eric Snowberg wrote:
> >> Move functionality within load_system_certificate_list
On Wed, Sep 30, 2020 at 04:15:07PM -0400, Eric Snowberg wrote:
> Move functionality within load_system_certificate_list to a common
> function, so it can be reused in the future.
>
> Signed-off-by: Eric Snowberg
I rather think now rather than the future. I think this should be part
of a patch
ed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
/Jarkko
On Wed, Sep 30, 2020 at 06:19:57AM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> > TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> > and the latter will be getting maintenance under TB. While this is not
&g
On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> and the latter will be getting maintenance under TB. While this is not
> preferred, we had to weigh this versus trying to convince you and the
> other TPM
On Tue, Sep 29, 2020 at 01:52:04PM -0400, Mimi Zohar wrote:
> On Mon, 2020-09-28 at 22:16 +0800, Kai-Heng Feng wrote:
> > Hi Jarkko,
> >
> > > On Sep 28, 2020, at 22:06, Jarkko Sakkinen
> > > wrote:
> > >
> > > On Mon, Sep 28, 2020 at 0
On Tue, Sep 29, 2020 at 12:52:35AM +0100, Andrew Cooper wrote:
> On 28/09/2020 21:42, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote:
> >> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> >>> On Fri, Sep 25, 2020 at 07:23:5
On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote:
> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
> >> I don’t personally care that much about EMODPE but, you could probably
> >> get the point
On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
> I don’t personally care that much about EMODPE but, you could probably
> get the point across with something like:
>
> SGX’s EPCM permission bits do not obviate the need to enforce these
> rules in the PTEs because enclaves can
On Mon, Sep 28, 2020 at 06:14:39PM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > > + spin_lock(_active_page_list_lock);
> >
On Mon, Sep 28, 2020 at 11:17:42AM -0700, Dave Hansen wrote:
> On 9/28/20 11:12 AM, Andy Lutomirski wrote:
> >> endbr64
> >> /* Check if shadow stack is in use. NB: R11 is the only usable
> >>scratch register for function calls. */
> >> xorl %r11d, %r11d
> >> rdsspq %r11
> >> testq %r11,
On Mon, Sep 28, 2020 at 11:12:08AM -0700, Andy Lutomirski wrote:
> On Mon, Sep 28, 2020 at 11:08 AM H.J. Lu wrote:
> >
> > On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper
> > wrote:
> > >
> > > On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > > &g
On Mon, Sep 28, 2020 at 11:07:47AM -0700, H.J. Lu wrote:
> On Mon, Sep 28, 2020 at 9:44 AM Andrew Cooper
> wrote:
> >
> > On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> > >> On
On Mon, Sep 28, 2020 at 08:54:01AM -0700, H.J. Lu wrote:
> On Mon, Sep 28, 2020 at 8:43 AM Yu, Yu-cheng wrote:
> >
> > On 9/25/2020 11:23 AM, Andrew Cooper wrote:
> > > On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > >> diff --git a/arch/x86/entry/vdso/vsg
On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote:
> On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> >> EMODPE is virtually irrelevant for this whole thing. The x86 PTE
> >> permissions still s
On Mon, Sep 28, 2020 at 08:43:16AM -0700, Yu, Yu-cheng wrote:
> On 9/25/2020 11:23 AM, Andrew Cooper wrote:
> > On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > > b/arch/x86/entry/vdso/vsgx_enter_enclave.S
On Mon, Sep 28, 2020 at 05:44:35PM +0100, Andrew Cooper wrote:
> On 28/09/2020 01:58, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> >> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> >>> diff --git a/arch/x86/entry/vdso/vsgx
On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote:
> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
> > My problem is that I fully agree what you say in your description but
> > disagree on that EMODPE should not be mentioned.
>
> I'll just be very clear: I'm not wil
On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote:
> On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> >> EMODPE is virtually irrelevant for this whole thing. The x86 PTE
> >> permissions still s
On Mon, Sep 28, 2020 at 06:15:00PM +0200, Ard Biesheuvel wrote:
> > > > It is possible but initially feels a bit weird:
> > > >
> > > > - sizeof(TCG_SPECID_SIG)) || count >
> > > > efispecid->num_algs) {
> > > > + sizeof(TCG_SPECID_SIG)) ||
> > > > +
On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> >> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >>>> That means that the intent a
On Mon, Sep 28, 2020 at 10:30:32AM +0200, Borislav Petkov wrote:
> On Mon, Sep 28, 2020 at 02:37:00AM +0300, Jarkko Sakkinen wrote:
> > I did not get Sean's reply, and neither can find it from lore:
> >
> > https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sak
On Thu, Sep 24, 2020 at 05:38:10PM -0700, Sean Christopherson wrote:
> > I can see why you would write "TCS" though - there's a thread control
> > structure thing too in that patch.
>
> Argh, it's actually supposed to be TCS, SGX_ENCLAVE_RUN_TSC is the one that's
> wrong.
So I presume that I
On Mon, Sep 28, 2020 at 08:20:18AM +0200, Ard Biesheuvel wrote:
> On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
> wrote:
> >
> >
> >
> > Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrot
On Mon, Sep 28, 2020 at 08:31:04PM +0800, Kai-Heng Feng wrote:
> Commit 7f3d176f5f7e "tpm: Require that all digests are present in
> TCG_PCR_EVENT2 structures" causes a null pointer dereference on all
> laptops I have:
...
> [ 17.868849] BUG: kernel NULL pointer dereference, address:
On Sun, Sep 27, 2020 at 01:06:03PM -0700, James Bottomley wrote:
> On Tue, 2019-11-26 at 08:17 -0500, Stefan Berger wrote:
> > From: Stefan Berger
> >
> > Revert the patch that was turning the TPM on before probing for IRQs.
> >
> > Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before
On Tue, Sep 15, 2020 at 02:05:19PM +0300, Jarkko Sakkinen wrote:
> +struct sgx_enclave_run {
> + __u64 tcs;
> + __u32 flags;
> + __u32 exit_reason;
> +
> + union {
> + sgx_enclave_exit_handler_t user_handler;
> + __u64 __use
On Fri, Sep 25, 2020 at 07:23:59PM +0100, Andrew Cooper wrote:
> On 15/09/2020 12:28, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > new file mode 100644
> > index ..adb
On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >> That means that the intent argument (SGX_PROT_*) is currently unused.
> > No, the intent argument is used (eventually) by SGX's ->mprotect()
> > implementation, i.e. sgx_mprotect()
On Fri, Sep 25, 2020 at 03:37:54PM -0700, Sean Christopherson wrote:
> On Tue, Sep 15, 2020 at 02:28:42PM +0300, Jarkko Sakkinen wrote:
> > Add the maintainer information for the SGX subsystem.
> >
> > Cc: Thomas Gleixner
> > Cc: Borislav Petkov
> &g
On Fri, Sep 25, 2020 at 05:32:50PM -0400, Daniel P. Smith wrote:
> The work for this is split across different teams with different
> resourcing levels resulting in one organization working Intel and
> another working AMD. This then raised the concern over submitting a
> single patch set developed
On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > > wrote:
>
On Fri, Sep 25, 2020 at 10:28:07AM +0200, Borislav Petkov wrote:
> > > I can see why you would write "TCS" though - there's a thread control
> > > structure thing too in that patch.
> >
> > Renamed.
>
> See Sean's reply.
I did not get Sean's reply, and neither can find it from lore:
The following commit has been merged into the perf/core branch of tip:
Commit-ID: e9ffc8c1b83931599663c21ba9082bcafa51d333
Gitweb:
https://git.kernel.org/tip/e9ffc8c1b83931599663c21ba9082bcafa51d333
Author:Jarkko Sakkinen
AuthorDate:Mon, 21 Sep 2020 21:24:25 -04:00
On Fri, Sep 25, 2020 at 09:51:04AM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 11:38:59PM +0300, Jarkko Sakkinen wrote:
> > I assume this is a rethorical question
>
> Of course - our text should not be write-only.
>
> > and I notice what I suggested
> &
On Fri, Sep 25, 2020 at 10:39:58AM +0200, Jethro Beekman wrote:
> On 2020-09-25 03:00, Jarkko Sakkinen wrote:
> > End result:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/include/uapi/asm/sgx.h
> >
>
On Fri, Sep 25, 2020 at 09:53:01AM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 11:40:22PM +0300, Jarkko Sakkinen wrote:
> > I'm not sure if I said it already but I also added cc to linux-mm (same
> > CC's in the patch as with mprotect callback commit). This should also
On Fri, Sep 25, 2020 at 10:14:41AM +0200, Borislav Petkov wrote:
> > > > +#define SGX_ENCLAVE_RUN_EXCEPTION 4*8
> > > > +
> > > > +#define SGX_SYNCHRONOUS_EXIT 0
> > > > +#define SGX_EXCEPTION_EXIT 1
> > >
> > > Those are in ...uapi/asm/sgx.h too. Unify?
>
On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> wrote:
> >
> > On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > > The TPM event log is provided to the OS by the firmware, by lo
fiReserved).
Makes perfect sense to the level that I wonder if this should have a
fixes tag and/or needs to be backported to the stable kernels?
> So instead, use memremap(), which will reuse the linear mapping if
> it is valid, or create another mapping otherwise.
>
> Cc: Peter Hu
On Fri, Sep 25, 2020 at 08:56:30AM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > The TPM event log is provided to the OS by the firmware, by loading
> > it into an area in memory and passing the physical address via a node
&g
On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
> above the TPM hardware interface.
>
> Signed-off-by: Daniel P. Smith
> Signed-off-by: Ross Philipson
This is way, way too PoC. I
On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote:
> The Trenchboot project focus on boot security has led to the enabling of
> the Linux kernel to be directly invocable by the x86 Dynamic Launch
> instruction(s) for establishing a Dynamic Root of Trust for Measurement
> (DRTM). The
On Thu, Sep 24, 2020 at 05:38:10PM -0700, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 08:04:07PM +0200, Borislav Petkov wrote:
> > On Tue, Sep 15, 2020 at 02:28:39PM +0300, Jarkko Sakkinen wrote:
> > > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> >
On Thu, Sep 24, 2020 at 08:04:07PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:39PM +0300, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > new file mode 100644
&
On Thu, Sep 24, 2020 at 06:31:28PM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:38PM +0300, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > index 9e5ec861aba0..ebe290a68c36 100644
> > --- a/arch/x86/mm/fault.c
> >
On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote:
> On 9/24/20 1:01 PM, Sean Christopherson wrote:
> >> In pseudo-C, it's something logically like this for the "nice" case:
> >>
> >>ptr = mmap("/some/executable", PROT_EXEC);
> >>ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC,
On Thu, Sep 24, 2020 at 12:28:54PM -0700, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> > On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> > wrote:
> > >I'll categorically deny noexec in the next patch set ver
On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> > For me this has caused months of confusion and misunderstanding of this
> > feature. I only recently realized that "oh, right, we invented this".
> >
> > They are contrived scenarios enough that they should be considered when
> >
On Thu, Sep 24, 2020 at 06:00:57PM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 03:09:01PM +0300, Jarkko Sakkinen wrote:
> > This is not technically SGX specific patch. Is SGX documentation the
> > correct place for this?
>
> So what is it then? It is SGX impleme
On Thu, Sep 24, 2020 at 11:39:07PM +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 05:57:51PM +0200, Borislav Petkov wrote:
> > On Thu, Sep 24, 2020 at 02:51:28PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
>
On Thu, Sep 24, 2020 at 05:57:51PM +0200, Borislav Petkov wrote:
> On Thu, Sep 24, 2020 at 02:51:28PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
> > > > Add 'access' implementation to vm_ops with the help of these functio
On Wed, Sep 23, 2020 at 05:55:11PM +0200, Borislav Petkov wrote:
> On Wed, Sep 23, 2020 at 05:47:07PM +0300, Jarkko Sakkinen wrote:
> > OK, so I did not follow this particular discussion in high detail,
>
> What do you mean you did not follow it? It is not a huge subthread in
On Thu, Sep 24, 2020 at 12:07:12AM +0200, Borislav Petkov wrote:
> On Tue, Sep 15, 2020 at 02:28:36PM +0300, Jarkko Sakkinen wrote:
> > From: Sean Christopherson
> >
> > The basic concept and implementation is very similar to the kernel's
> > exception fixup mech
On Wed, Sep 23, 2020 at 06:17:33PM +0200, Borislav Petkov wrote:
> > Add 'access' implementation to vm_ops with the help of these functions.
>
> "Add an ->access virtual MM function for accessing the enclave's memory... "
Thank you. I wrote the last paragraph like this:
"Add an '->access'
On Wed, Sep 23, 2020 at 03:50:05PM +0200, Borislav Petkov wrote:
> > +This leaf function takes an RSA-3072 signature of the enclave measurement
> > and an
> > +optional cryptographic token. Linux does not take advantage of launch
> > tokens.
> > +The instruction checks that the signature is
> if (IS_ERR(va_page)) <- needed a new VA page, allocation failed
> return PTR_ERR(va_page);
> else if (va_page)<- needed a new VA page, allocation succeeded
> list_add(_page->list, >va_pages);
> else
><- reused the
On Tue, Sep 22, 2020 at 04:24:13PM +0200, Borislav Petkov wrote:
> On Tue, Sep 22, 2020 at 05:03:23PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > > > + * %SGX_ENCL_PAGE_VA_OFFSET_MASK: Holds the offset in the V
On Tue, Sep 22, 2020 at 04:29:09PM +0200, Borislav Petkov wrote:
> On Tue, Sep 22, 2020 at 02:56:19PM +0200, Jethro Beekman wrote:
> > I don't see why you'd need to retry indefinitely. Yes the MSRs may not
> > match the cached value for “reasons”, but if after you've written
> > them once it still
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> Now I'm confused. I actually don't think I have a strong understanding
> of how an enclave actually gets loaded, how mmap() and mprotect() are
> normally used and what this hook is intended to thwart.
You saw my other comments. I
On Tue, Sep 22, 2020 at 09:43:02AM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> On 9/22/20 5:58 AM, Jarkko Sakkinen wrote:
> > Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> > called enclaves, of which page permissions are defined when the enclave
>
> &qu
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> > Enclave permissions can be dynamically modified by using ENCLS[EMODPE]
>
> I'm not sure this sentence matters. I'm not sure why I care what the
> instruction is named that does this. But, it _sounds_ here like an
> enclave can
On Tue, Sep 22, 2020 at 05:44:24PM +0200, Borislav Petkov wrote:
>
> > Subject: Re: [PATCH v38 17/24] x86/sgx: ptrace() support for the SGX driver
>... x86/sgx: Add ptrace() support...
>
> subject needs a verb.
>
> On Tue, Sep 15, 2020 at
On Tue, Sep 22, 2020 at 12:45:38PM +0200, Borislav Petkov wrote:
> > + * %SGX_ENCL_PAGE_VA_OFFSET_MASK: Holds the offset in the Version Array
> > + * (VA) page for a swapped page.
> > * %SGX_ENCL_PAGE_ADDR_MASK: Holds the virtual address of
> > the
On Tue, Sep 22, 2020 at 10:29:18AM +0200, Borislav Petkov wrote:
> On Mon, Sep 21, 2020 at 12:17:00PM -0700, Sean Christopherson wrote:
> > That was effectively my original suggestion as well, check for a stale cache
> > and retry indefinitely. I capitulated because it did feel like I was being
>
On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wro
On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wro
On Mon, Sep 21, 2020 at 09:41:56PM +0200, Borislav Petkov wrote:
> On Mon, Sep 21, 2020 at 10:27:06PM +0300, Jarkko Sakkinen wrote:
> > 'sgx_dev_enclave' is successfully register whenever that happens. Am I
> > missing something here?
>
> No, I was missing the fact tha
On Mon, Sep 21, 2020 at 12:57:39PM -0700, Sean Christopherson wrote:
> On Mon, Sep 21, 2020 at 10:44:19PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 09:49:48PM +0300, Jarkko Sakkinen wrote:
> > > To have understandable semantics you have to map error codes to
>
On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > a noexec filesystem by loading code into an enclave, and to give
On Mon, Sep 21, 2020 at 10:44:19PM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 21, 2020 at 09:49:48PM +0300, Jarkko Sakkinen wrote:
> > To have understandable semantics you have to map error codes to
> > conditions rather than opcodes. -EIO means loss of enclave in the event
On Mon, Sep 21, 2020 at 09:49:48PM +0300, Jarkko Sakkinen wrote:
> To have understandable semantics you have to map error codes to
> conditions rather than opcodes. -EIO means loss of enclave in the event
> of EPC gone invalid. Enclave is already lost, that is the reason why we
>
On Mon, Sep 21, 2020 at 03:51:07PM +0200, Borislav Petkov wrote:
> > "... after checking that the provided data for SECS meets the expectations
> > of ENCLS[ECREATE] for an unitialized enclave and size of the address
There is a typo (should be uninitialized).
> > Is this sufficient for you, or
801 - 900 of 8077 matches
Mail list logo
