Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
From: "Xing, Cedric" <cedric.xing@intel.com>
To: "Christopherson, Sean J" <sean.j.christopherson@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"Ayoun, Serge" <serge.ayoun@intel.com>,
	"Katz-zamir, Shay" <shay.katz-zamir@intel.com>,
	"Huang, Haitao" <haitao.huang@intel.com>,
	"Svahn, Kai" <kai.svahn@intel.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"jarkko.sakkinen@linux.intel.com"
	<jarkko.sakkinen@linux.intel.com>
Subject: RE: [RFC PATCH v2 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack
Date: Thu, 25 Apr 2019 23:31:40 +0000
Message-ID: <960B34DE67B9E140824F1DCDEC400C0F4E87FD17@ORSMSX116.amr.corp.intel.com> (raw)
In-Reply-To: <20190424190446.GE18442@linux.intel.com>

Hi Sean,

> AIUI, you and Andy had an off-list discussion regarding rewriting
> __vdso_sgx_enter_enclave() vs. providing a second vDSO function.  Can
> you
> please summarize the discussion so that it's clear why you're pursuing a
> single function?
> 
> In the end I probably agree that's it's desirable to have a single ABI
> and
> vDSO function since the cost is basically that the non-callback case
> needs
> to pass params via the stack instead of registers, but I do miss the
> simplicity of separate implementations.
> 

The major reason is we don't want to maintain 2 different ABIs (preserving %rsp vs. %rbp). Given the new one covers all known use cases, we prefer not to keep the other one.

> > Here's the summary of API/ABI changes in this patch. More details
> could be
> > found in arch/x86/entry/vdso/vsgx_enter_enclave.S.
> > * 'struct sgx_enclave_exception' is renamed to 'struct
> sgx_enclave_exinfo'
> >   because it is filled upon both AEX (i.e. exceptions) and normal
> enclave
> >   exits.
> > * __vdso_sgx_enter_enclave() anchors its frame using %rbp (instead
> of %rsp in
> >   the previous implementation).
> > * __vdso_sgx_enter_enclave() takes one more parameter - a callback
> function to
> >   be invoked upon enclave exits. This callback is optional, and if not
> >   supplied, will cause __vdso_sgx_enter_enclave() to return upon
> enclave exits
> >   (same behavior as previous implementation).
> > * The callback function is given as a parameter the value of %rsp at
> enclave
> >   exit to address data "pushed" by the enclave. A positive value
> returned by
> >   the callback will be treated as an ENCLU leaf for re-entering the
> enclave,
> >   while a zero or negative value will be passed through as the return
> >   value of __vdso_sgx_enter_enclave() to its caller. It's also safe to
> >   leave callback by longjmp() or by throwing a C++ exception.
> >
> > Signed-off-by: Cedric Xing <cedric.xing@intel.com>
> > ---
> >  arch/x86/entry/vdso/vsgx_enter_enclave.S | 175 ++++++++++++++++------
> -
> >  arch/x86/include/uapi/asm/sgx.h          |  14 +-
> >  2 files changed, 128 insertions(+), 61 deletions(-)
> >
> > diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > index fe0bf6671d6d..debecb0d785c 100644
> > --- a/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S
> > @@ -19,83 +19,150 @@
> >   * __vdso_sgx_enter_enclave() - Enter an SGX enclave
> >   *
> >   * @leaf:	**IN \%eax** - ENCLU leaf, must be EENTER or ERESUME
> > - * @tcs:	**IN \%rbx** - TCS, must be non-NULL
> > - * @ex_info:	**IN \%rcx** - Optional 'struct sgx_enclave_exception'
> pointer
> > + * @tcs:	**IN 0x08(\%rsp)** - TCS, must be non-NULL
> > + * @ex_info:	**IN 0x10(\%rsp)** - Optional 'struct
> sgx_enclave_exinfo'
> > + *				     pointer
> > + * @callback:	**IN 0x18(\%rsp)** - Optional callback function to
> be called on
> > + *				     enclave exit or exception
> >   *
> >   * Return:
> >   *  **OUT \%eax** -
> > - *  %0 on a clean entry/exit to/from the enclave, %-EINVAL if ENCLU
> leaf is
> > - *  not allowed or if TCS is NULL, %-EFAULT if ENCLU or the enclave
> faults
> > + *  %0 on a clean entry/exit to/from the enclave, %-EINVAL if ENCLU
> leaf is not
> > + *  allowed, %-EFAULT if ENCLU or the enclave faults, or a non-
> positive value
> > + *  returned from ``callback`` (if one is supplied).
> >   *
> >   * **Important!**  __vdso_sgx_enter_enclave() is **NOT** compliant
> with the
> > - * x86-64 ABI, i.e. cannot be called from standard C code.   As noted
> above,
> > - * input parameters must be passed via ``%eax``, ``%rbx`` and
> ``%rcx``, with
> > - * the return value passed via ``%eax``.  All registers except
> ``%rsp`` must
> > - * be treated as volatile from the caller's perspective, including
> but not
> > - * limited to GPRs, EFLAGS.DF, MXCSR, FCW, etc...  Conversely, the
> enclave
> > - * being run **must** preserve the untrusted ``%rsp`` and stack.
> > + * x86-64 ABI, i.e. cannot be called from standard C code. As noted
> above,
> > + * input parameters must be passed via ``%eax``, ``8(%rsp)``,
> ``0x10(%rsp)`` and
> > + * ``0x18(%rsp)``, with the return value passed via ``%eax``. All
> other
> > + * registers will be passed through to the enclave as is. All
> registers except
> > + * ``%rbp`` must be treated as volatile from the caller's perspective,
> including
> 
> Hmm, this is my fault since I wrote the original comment, but stating
> "All registers except %rbp must be treated as volatile" is confusing,
> e.g.
> at first I thought it meant that the assembly blob was mucking with the
> registers and that they couldn't be used to pass information out of the
> enclave.
> 
> Maybe something like:
> 
>  * Register ABI:
>  *  - As noted above, input parameters are passed via %eax and the stack.
>  *  - The return value is passed via %eax.
>  *  - %rbx and %rcx must be treated as volatile as they are modified as
> part of
>  *    enclaves transitions and are used as scratch regs.
>  *  - %rbp **must** be preserved by the enclave in all cases, as it is
> used to
>  *    reference paramaters when handling enclave exits.
>  *  - %rdx, %rdi, %rsi and %r8-%r15 may be freely modified by the
> enclave
>  *    and will not be passed back to the caller untouched.
>  *  - %rsp is saved/restored across __vdso_sgx_enter_enclave(), but is
> passed
>  *    as-is to the callback if one is provided, i.e. the enclave may use
> u_rsp
>  *    to pass information to its associated callback.
>  *
>  * Callback ABI:
>  *  <more information about callback ABI>
>  *

Really appreciated! I'll update the comments in the next revision.

> 
> > + * but not limited to GPRs, EFLAGS.DF, MXCSR, FCW, etc... Conversely,
> the
> > + * enclave being run **must** preserve the untrusted ``%rbp``.
> > + *
> > + * ``callback`` has the following signature:
> > + * int callback(long rdi, long rsi, long rdx,
> > + *		struct sgx_enclave_exinfo *exinfo, long r8, long r9,
> > + *		void *tcs, long ursp);
> > + * ``callback`` **shall** follow x86_64 ABI. All GPRs **except**
> ``%rax``,
> > + * ``%rbx`` and ``rcx`` are passed through to ``callback``. ``%rdi``,
> ``%rsi``,
> > + * ``%rdx``, ``%r8``, ``%r9``, along with the value of ``%rsp`` when
> the enclave
> > + * exited/excepted, can be accessed directly as input parameters,
> while other
> > + * GPRs can be accessed in assembly if needed.  A positive value
> returned from
> > + * ``callback`` will be treated as an ENCLU leaf (e.g. EENTER/ERESUME)
> to
> > + * reenter the enclave (without popping the extra data pushed by the
> enclave off
> > + * the stack), while 0 (zero) or a negative return value will be
> passed back to
> > + * the caller of __vdso_sgx_enter_enclave(). It is also safe to leave
> > + * ``callback`` via ``longjmp()`` or by throwing a C++ exception.
> >   */
> 
> While this may format nicely in .rst (I haven't checked), it's damn near
> unreadable in its raw form.  Escaping '%' in kernel-doc is unresolved at
> this point, but this definitely is an argument for allowing the %CONST
> interpretation to be disabled entirely.
> 

I know very little about kernel-doc. Not quite sure which markup means what. Or if you don't mind, could you just write up the whole thing (you have written half of it in your email already) so I can include it into my next revision?
 
> longjmp() is probably the only thing that needs to be explicitly marked,
> I think it would be better to simply say "the callback" instead of using
> ``callback``, i.e. use regular English instead of referencing the param.
> 

Are you suggesting not to mention C++ exception here?
 
> > -__vdso_sgx_enter_enclave(u32 leaf, void *tcs,
> > -			 struct sgx_enclave_exception *ex_info)
> > +typedef int (*sgx_callback)(long rdi, long rsi, long rdx,
> > +			    struct sgx_enclave_exinfo *exinfo, long r8,
> > +			    long r9, void *tcs, long ursp);
> > +int __vdso_sgx_enter_enclave(int leaf, void *tcs,
> > +			     struct sgx_enclave_exinfo *exinfo,
> > +			     sgx_callback callback)
> >  {
> > -	if (leaf != SGX_EENTER && leaf != SGX_ERESUME)
> > -		return -EINVAL;
> > -
> > -	if (!tcs)
> > -		return -EINVAL;
> > -
> > -	try {
> > -		ENCLU[leaf];
> > -	} catch (exception) {
> > -		if (e)
> > -			*e = exception;
> > -		return -EFAULT;
> > +	while (leaf == EENTER || leaf == ERESUME) {
> 
> This gives the impression that looping is the common case.  I'd prefer
> using 'goto' to show that the common case is a simple fall through
> whereas
> the callback case can effectively loop on ENCLU.

Looping IMO is indeed the common case. Just think of the case of an enclave making a sequence of o-calls. 
 
> 
> > +		int rc;
> > +		try {
> > +			ENCLU[leaf];
> > +			rc = 0;
> > +			if (exinfo)
> > +				exinfo->leaf = EEXIT;
> > +		} catch (exception) {
> > +			rc = -EFAULT;
> > +			if (exinfo)
> > +				*exinfo = exception;
> > +		}
> > +
> > +		leaf = callback ? (*callback)(
> > +			rdi, rsi, rdx, exinfo, r8, r9, tcs, ursp) : rc;
> >  	}
> >
> > -	return 0;
> > +	return leaf > 0 ? -EINVAL : leaf;
> >  }
> >  #endif
> >  ENTRY(__vdso_sgx_enter_enclave)
> > -	/* EENTER <= leaf <= ERESUME */
> > +	/* Prolog */
> > +	.cfi_startproc
> > +	push	%rbp
> > +	.cfi_adjust_cfa_offset	8
> > +	.cfi_rel_offset		%rbp, 0
> > +	mov	%rsp, %rbp
> > +	.cfi_def_cfa_register	%rbp
> > +
> > +1:	/* EENTER <= leaf <= ERESUME */
> >  	cmp	$0x2, %eax
> > -	jb	bad_input
> > -
> > +	jb	6f
> >  	cmp	$0x3, %eax
> > -	ja	bad_input
> > +	ja	6f
> >
> > -	/* TCS must be non-NULL */
> > -	test	%rbx, %rbx
> > -	je	bad_input
> > +	/* Load TCS and AEP */
> > +	mov	0x10(%rbp), %rbx
> > +	lea	2f(%rip), %rcx
> >
> > -	/* Save @exception_info */
> > -	push	%rcx
> > +	/* Single ENCLU serving as both EENTER and AEP (ERESUME) */
> > +2:	enclu
> >
> > -	/* Load AEP for ENCLU */
> > -	lea	1f(%rip),  %rcx
> > -1:	enclu
> > +	/* EEXIT path */
> > +	xor	%ebx, %ebx
> > +3:	mov	0x18(%rbp), %rcx
> 
> @exinfo is optional, i.e. %ecx needs to be tested before its used.
> 
> > +	jrcxz	4f

The above instruction (i.e. jrcxz) does test %rcx.

> 
> I dislike the number of flags and values that are stashed away only to
> be consumed later, it makes the code hard to follow.  AFAICT, a lot of
> the shenanigans are done to reuse code because exinfo was overloaded,
> but that's actually pointless, i.e. it's unnecessarily complex.
> 
> Overlading the struct is pointless becase if you make it mandatory when
> using a callback then it can be nullified (when passed to the callback)
> to indicate EEXIT.  If it's still optional, then the callback needs an
> extra param to explicitly indicate EEXIT vs. -EFAULT, otherwise the
> callback has no indication whatsover of why it was invoked.
> 
> My preference is for the latter since it's more explicit and obvious.

I wouldn't nullify @exinfo at EEXIT because that could be used as a "context" pointer to the callback.

Making it optionally because the callback can still use other registers (e.g. %rdi) determine the reason without it. For example, an enclave may set %rdi to non-zero to signify o-call/e-ret while zero (as set by AEX) would indicate an exception. My intention is not to impose unnecessary restrictions on applications.

> 
> Tangetially related, I'm not opposed to renaming it
> 'struct sgx_enclave_exception_info' for clarity.

I'd still prefer sgx_enclave_exinfo to imply its use in both _ex_it and _ex_ception cases, for the reason stated above.

> 
> > +	mov	%eax, EX_LEAF(%rcx)
> > +	jnc	4f
> > +	mov	%di, EX_TRAPNR(%rcx)
> > +	mov	%si, EX_ERROR_CODE(%rcx)
> > +	mov	%rdx, EX_ADDRESS(%rcx)
> 
> My strong preference would be to organize the code to separate the
> various
> flows, i.e. happy common case, invalid input, exception handler and
> callback invocation.  And make the common case a straight shot so that
> it's more obvious what happens in the happy non-callback case.

I'd prefer more concise code. After all, this is assembly without optimization done by the compiler. If it were for C, I'd agree with you because either case would end up in roughly the same code (in terms of code size or efficiency) due to the optimizer.

> >
> > -	add	$0x8, %rsp
> > -	xor	%eax, %eax
> > +4:	/* Call *callback if supplied */
> > +	mov	0x20(%rbp), %rax
> > +	test	%rax, %rax
> > +	/* At this point, %ebx holds the effective return value, which
> shall be
> > +	 * returned if no callback is specified */
> 
> Use kernel-doc format for multi-line comments.  Missing punctionation at
> the end.  Blank lines between logical blocks would also help readability.
> 
> E.g.:
> 
> 4:      /* Call *callback if supplied */
>         mov     0x20(%rbp), %rax
>         test    %rax, %rax
> 
>         /*
>          * At this point, %ebx holds the effective return value, which
> shall be
>          * returned if no callback is specified.
>          */
>         cmovz   %rbx, %rax
>         jz      7f

I know very little about kernel-doc. Would you please point me to documents describing it? What you suggested here will of course be incorporated into my next revision. 

> > +	cmovz	%rbx, %rax
> > +	jz	7f
> > +	/* Align stack per x86_64 ABI. The original %rsp is saved in %rbx
> to be
> > +	 * restored after *callback returns. */
> > +	mov	%rsp, %rbx
> > +	and	$-0x10, %rsp
> > +	/* Clear RFLAGS.DF per x86_64 ABI */
> > +	cld
> > +	/* Parameters for *callback */
> > +	push	%rbx
> > +	push	0x10(%rbp)
> > +	/* Call *%rax via retpoline */
> > +	call	40f
> 
> Another case of stashing a value it consuming it later.  This one is
> especially brutal since %rax was loaded with CMOVcc, which means the
> reader needs to backtrack even further to understand what %rax contains
> at this point.

%rax was loaded only 2 instructions ago, while what %rbx is containing is described in the comment immediately above it. I think I have done my best to make it readable. After all, this is assembly so can't expect something like giving proper names to variables in C because that just can't be done in assembly.

> 
> > +	/* Restore %rsp to its original value left off by the enclave from
> last
> > +	 * exit */
> > +	mov	%rbx, %rsp
> > +	/* Positive return value from *callback will be interpreted as an
> ENCLU
> > +	 * leaf, while a non-positive value will be interpreted as the
> return
> > +	 * value to be passed back to the caller. */
> 
> Please use imperative mood in the comments, i.e. simply state what the
> code is doing.  E.g. "will be interpreted" makes it sound like something
> else is processing the callback's return value.

Will do in the next revision.

> > +	jmp	1b
> > +40:	/* retpoline */
> > +	call	42f
> > +41:	pause
> > +	lfence
> > +	jmp	41b
> > +42:	mov	%rax, (%rsp)
> >  	ret
> >
> > -bad_input:
> > -	mov     $(-EINVAL), %rax
> > -	ret
> > +5:	/* Exception path */
> > +	mov	$-EFAULT, %ebx
> > +	stc
> > +	jmp	3b
> >
> > -.pushsection .fixup, "ax"
> > -	/* Re-load @exception_info and fill it (if it's non-NULL) */
> > -2:	pop	%rcx
> > -	test    %rcx, %rcx
> > -	je      3f
> > +6:	/* Unsupported ENCLU leaf */
> > +	cmp	$0, %eax
> > +	jle	7f
> > +	mov	$-EINVAL, %eax
> >
> > -	mov	%eax, EX_LEAF(%rcx)
> > -	mov	%di,  EX_TRAPNR(%rcx)
> > -	mov	%si,  EX_ERROR_CODE(%rcx)
> > -	mov	%rdx, EX_ADDRESS(%rcx)
> > -3:	mov	$(-EFAULT), %rax
> > +7:	/* Epilog */
> > +	leave
> > +	.cfi_def_cfa		%rsp, 8
> >  	ret
> > -.popsection
> > +	.cfi_endproc
> >
> > -_ASM_VDSO_EXTABLE_HANDLE(1b, 2b)
> > +_ASM_VDSO_EXTABLE_HANDLE(2b, 5b)
> >
> >  ENDPROC(__vdso_sgx_enter_enclave)
> 
> Putting everything together, sans comments, I'd prefer something like
> the
> following.  Pasted in raw code as that'll hopefully be easier to review
> and discuss than a diff.
> 
> Note, swapping 'long rc' and '... *e' would allow the callback flow
> to save one memory access, but IMO the exception info belongs at the end
> since it's optional.

You have probably misunderstood my code. 'ret' is _not_ passed while @exinfo is passed in %rcx. exinfo->leaf implies the reason of the callback.

Or are you suggesting to add 'ret' as one more parameter to the callback? I don't think it necessary because exinfo contains everything the callback would ever need.

> #ifdef SGX_KERNEL_DOC
> typedef int (*sgx_callback)(long rdi, long rsi, long rdx, long ret, long
> r8,
> 			    long r9, void *tcs, long ursp,
> 			    struct sgx_enclave_exception_info *e);
> int __vdso_sgx_enter_enclave(int leaf, void *tcs,
> 				struct sgx_enclave_exception_info *e,
> 				sgx_callback callback)
> {
> 	int ret;
> 
> enter_enclave:
> 	if (leaf != EENTER && leaf != ERESUME) {
> 		ret = -EINVAL;
> 		goto out;
> 	}
> 
> 	try {
> 		ENCLU[leaf];
> 		ret = 0;
> 	} catch (exception) {
> 		ret = -EFAULT;
> 		if (e)
> 			*e = exception;
> 	}
> 	if (callback)
> 		goto do_callback;
> out:
> 	return ret;
> 
> do_callback:
> 	leaf = (*callback)(rdi, rsi, rdx, ret, r8, r9, e, tcs, ursp);
> 	if (leaf <= 0)
> 		goto out;
> 	goto enter_enclave;
> }
> #endif
> ENTRY(__vdso_sgx_enter_enclave)
> 	/* Prolog */
> 	.cfi_startproc
> 	push	%rbp
> 	.cfi_adjust_cfa_offset	8
> 	.cfi_rel_offset		%rbp, 0
> 	mov	%rsp, %rbp
> 	.cfi_def_cfa_register	%rbp
> 
> 1:	/* EENTER <= leaf <= ERESUME */
> 	cmp	$0x2, %eax
> 	jb	5f
> 	cmp	$0x3, %eax
> 	ja	5f
> 
> 	/* Load TCS and AEP */
> 	mov	0x10(%rbp), %rbx
> 	lea	2f(%rip), %rcx
> 
> 	/* Single ENCLU serving as both EENTER and AEP (ERESUME) */
> 2:	enclu
> 
> 	/* EEXIT branches here unless the enclave is doing something fancy.
> */
> 	xor	%eax, %eax
> 
> 3:	cmp	$0, 0x20(%rbp)
> 	jne	8f
> 
> 4:	leave
> 	.cfi_def_cfa		%rsp, 8
> 	ret
> 
> 5:	mov	$(-EINVAL), %rax
> 	jmp	4b
> 
> 6:	mov	0x18(%rbp), %rcx
> 	test    %rcx, %rcx
> 	je	7f
> 
> 	/* Fill optional exception info. */
> 	mov	%eax, EX_LEAF(%rcx)
> 	mov	%di,  EX_TRAPNR(%rcx)
> 	mov	%si,  EX_ERROR_CODE(%rcx)
> 	mov	%rdx, EX_ADDRESS(%rcx)
> 7:	mov	$(-EFAULT), %rax
> 	jmp	3b
> 
> 8:	/*
> 	 * Align stack per x86_64 ABI.  Save the original %rsp in %rbx to
> be
> 	 * restored after the callback returns.
> 	 */
> 	mov	%rsp, %rbx
> 	and	$-0x10, %rsp
> 
> 	/* Push @e, u_rsp and @tcs as parameters to the callback. */
> 	push	0x18(%rbp)
> 	push	%rbx
> 	push	0x10(%rbp)
> 
> 	/* Pass the "return value" to the callback via %rcx. */
> 	mov	%rax, %rcx
> 
> 	/* Clear RFLAGS.DF per x86_64 ABI */
> 	cld
> 
> 	/* Load the callback pointer to %rax and invoke it via retpoline.
> */
> 	mov	0x20(%rbp), %rax
> 	call	40f
> 
> 	/* Restore %rsp to its post-exit value. */
> 	mov	%rbx, %rsp
> 
> 	/*
> 	 * If the return from callback is zero or negative, return
> immediately,
> 	 * otherwise attempt to re-execute ENCLU with the return
> interpreted as
> 	 * the requested ENCLU leaf.
> 	 */
> 	cmp	$0, %eax
> 	jle	4b
> 	jmp	1b
> 
> 40:	/* retpoline */
> 	call	42f
> 41:	pause
> 	lfence
> 	jmp	41b
> 42:	mov	%rax, (%rsp)
> 	ret
> 	.cfi_endproc
> 
> _ASM_VDSO_EXTABLE_HANDLE(2b, 6b)
> 
> ENDPROC(__vdso_sgx_enter_enclave)

Your code will work. The only missing thing is a ".cfi_def_cfa %rbp, 16" after 'ret' instruction in block 4. I decided to keep "leave; ret" at the end to avoid confusion around the frame pointer. As you may also notice, GCC generated code usually does the same thing. 

-Cedric

  reply index

Thread overview: 318+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17 10:39 [PATCH v20 00/28] Intel SGX1 support Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 01/28] x86/cpufeatures: Add Intel-defined SGX feature bit Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 02/28] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits) Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 03/28] x86/msr: Add IA32_FEATURE_CONTROL.SGX_ENABLE definition Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 04/28] x86/cpufeatures: Add Intel-defined SGX_LC feature bit Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 05/28] x86/msr: Add SGX Launch Control MSR definitions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 06/28] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 07/28] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 08/28] x86/cpu/intel: Detect SGX support and update caps appropriately Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 09/28] x86/sgx: Add ENCLS architectural error codes Jarkko Sakkinen
2019-04-22 21:35   ` Sean Christopherson
2019-04-17 10:39 ` [PATCH v20 10/28] x86/sgx: Add SGX1 and SGX2 architectural data structures Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 11/28] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 12/28] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 13/28] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 14/28] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver Jarkko Sakkinen
2019-04-22 21:58   ` Sean Christopherson
2019-04-23 23:29     ` Jethro Beekman
2019-04-24  0:26       ` Sean Christopherson
2019-04-24  1:04         ` Jethro Beekman
2019-04-29 19:08           ` Sean Christopherson
2019-06-04 20:12         ` Sean Christopherson
2019-06-05 14:29           ` Jarkko Sakkinen
2019-06-05 14:52             ` Sean Christopherson
2019-06-05 21:25               ` Dr. Greg
2019-06-05 22:20                 ` Sean Christopherson
2019-06-06 15:32               ` Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 16/28] x86/sgx: Add provisioning Jarkko Sakkinen
2019-04-19  3:06   ` Huang, Kai
2019-04-23 14:33     ` Jarkko Sakkinen
2019-04-24  1:34   ` Jethro Beekman
2019-05-02  8:27     ` Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 17/28] x86/sgx: Add swapping code to the core and SGX driver Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 18/28] x86/sgx: ptrace() support for the " Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 19/28] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 20/28] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 21/28] x86/fault: Attempt to fixup unhandled #PF in vDSO before signaling Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 22/28] x86/traps: Attempt to fixup exceptions " Jarkko Sakkinen
2019-06-25 15:43   ` Jarkko Sakkinen
2019-06-27 20:32     ` Xing, Cedric
2019-07-11 15:54       ` Sean Christopherson
2019-07-11 22:12         ` Xing, Cedric
2019-07-11 15:56     ` Sean Christopherson
2019-07-11 17:52       ` Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 23/28] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 24/28] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 25/28] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 26/28] docs: x86/sgx: Add Architecture documentation Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 27/28] docs: x86/sgx: Document kernel internals Jarkko Sakkinen
2019-04-17 10:39 ` [PATCH v20 28/28] docs: x86/sgx: Document the enclave API Jarkko Sakkinen
2019-04-18 17:10 ` [PATCH v20 00/28] Intel SGX1 support Dr. Greg
2019-04-18 17:24   ` Dave Hansen
2019-04-19 16:24     ` Dr. Greg
2019-04-19 16:39       ` Dave Hansen
2019-04-18 18:01   ` Dave Hansen
2019-04-19 14:17     ` Dr. Greg
2019-04-19 14:25       ` Dave Hansen
2019-04-19 15:27       ` Andy Lutomirski
2019-04-19 19:38         ` Jethro Beekman
2019-04-19 20:39           ` Thomas Gleixner
2019-04-19 20:46             ` Jethro Beekman
2019-04-19 20:50               ` Thomas Gleixner
2019-04-19 20:54                 ` Jethro Beekman
2019-04-19 21:15                   ` Andy Lutomirski
2019-04-19 21:19                     ` Jethro Beekman
2019-04-19 21:31                       ` Andy Lutomirski
2019-04-19 21:35                         ` Jethro Beekman
2019-04-19 21:38                           ` Thomas Gleixner
2019-04-19 21:56                             ` Jethro Beekman
2019-04-20  5:42                               ` Thomas Gleixner
2019-04-20 16:02                                 ` Dr. Greg
2019-04-22 15:01                                   ` Sean Christopherson
2019-04-22 16:24                                     ` Dr. Greg
2019-04-22 16:48                                       ` Sean Christopherson
2019-04-22 16:55                                         ` Linus Torvalds
2019-04-22 17:17                                           ` Sean Christopherson
2019-04-23  9:11                                             ` Dr. Greg
2019-04-22 16:26                               ` Andy Lutomirski
2019-04-23 21:15                                 ` Jethro Beekman
2019-05-10 17:23                                 ` Xing, Cedric
2019-05-10 17:37                                   ` Jethro Beekman
2019-05-10 17:54                                     ` Dave Hansen
2019-05-10 18:04                                       ` Jethro Beekman
2019-05-10 18:56                                         ` Xing, Cedric
2019-05-10 19:04                                           ` Jethro Beekman
2019-05-10 19:22                                             ` Andy Lutomirski
2019-05-11  1:06                                               ` Xing, Cedric
2019-05-14 15:08                                                 ` Andy Lutomirski
2019-05-15  8:31                                                   ` Jarkko Sakkinen
     [not found]                                               ` <20190513102926.GD8743@linux.intel.com>
2019-05-14 10:43                                                 ` Jarkko Sakkinen
2019-05-14 15:13                                                   ` Andy Lutomirski
2019-05-14 20:45                                                     ` Sean Christopherson
2019-05-14 21:27                                                       ` Andy Lutomirski
2019-05-14 22:28                                                         ` Xing, Cedric
2019-05-15  1:30                                                         ` Sean Christopherson
2019-05-15 18:27                                                           ` SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Andy Lutomirski
2019-05-15 19:58                                                             ` James Morris
2019-05-15 20:35                                                               ` Andy Lutomirski
2019-05-15 22:46                                                                 ` James Morris
2019-05-15 23:13                                                                   ` Andy Lutomirski
2019-05-16  3:03                                                                     ` Xing, Cedric
2019-05-16  4:40                                                                       ` Andy Lutomirski
2019-05-16 22:23                                                                         ` Xing, Cedric
2019-05-17  0:35                                                                           ` Andy Lutomirski
2019-05-17  1:06                                                                             ` Xing, Cedric
2019-05-17  1:21                                                                               ` Andy Lutomirski
2019-05-17 16:05                                                                             ` Sean Christopherson
2019-05-17 13:53                                                                           ` Stephen Smalley
2019-05-17 15:09                                                                             ` Sean Christopherson
2019-05-17 16:20                                                                               ` Stephen Smalley
2019-05-17 16:24                                                                                 ` Andy Lutomirski
2019-05-17 16:37                                                                                 ` Stephen Smalley
2019-05-17 17:12                                                                                   ` Andy Lutomirski
2019-05-17 18:05                                                                                     ` Stephen Smalley
2019-05-17 19:20                                                                                       ` Stephen Smalley
2019-05-17 19:28                                                                                       ` Sean Christopherson
2019-05-17 20:09                                                                                         ` Stephen Smalley
2019-05-17 20:14                                                                                           ` Andy Lutomirski
2019-05-17 20:34                                                                                             ` Stephen Smalley
2019-05-17 21:36                                                                                           ` Sean Christopherson
2019-05-17 17:29                                                                                   ` Sean Christopherson
2019-05-17 17:42                                                                                     ` Stephen Smalley
2019-05-17 17:50                                                                                       ` Sean Christopherson
2019-05-17 18:16                                                                                         ` Stephen Smalley
2019-05-17 17:43                                                                                     ` Andy Lutomirski
2019-05-17 17:55                                                                                       ` Sean Christopherson
2019-05-17 18:04                                                                                         ` Linus Torvalds
2019-05-17 18:21                                                                                           ` Sean Christopherson
2019-05-17 18:33                                                                                             ` Linus Torvalds
2019-05-17 18:52                                                                                               ` Sean Christopherson
2019-05-17 18:53                                                                                             ` Andy Lutomirski
2019-05-16  7:24                                                                     ` James Morris
2019-05-16 21:00                                                                       ` Andy Lutomirski
2019-05-20  9:38                                                                       ` Dr. Greg
2019-05-15 21:38                                                             ` Sean Christopherson
2019-05-16  1:19                                                               ` Haitao Huang
2019-05-16  5:16                                                             ` Jarkko Sakkinen
2019-05-16 21:02                                                               ` Andy Lutomirski
2019-05-16 22:45                                                                 ` Sean Christopherson
2019-05-16 23:29                                                                   ` Xing, Cedric
2019-05-20 11:29                                                                   ` Jarkko Sakkinen
2019-05-20 11:33                                                                 ` Jarkko Sakkinen
2019-05-17  0:03                                                             ` Sean Christopherson
2019-05-17  0:26                                                               ` Andy Lutomirski
2019-05-17 15:41                                                                 ` Sean Christopherson
2019-05-20 11:42                                                                   ` Jarkko Sakkinen
2019-05-20 11:41                                                                 ` Jarkko Sakkinen
2019-05-21 15:19                                                                   ` Jarkko Sakkinen
2019-05-21 15:24                                                                     ` Jethro Beekman
2019-05-22 13:10                                                                       ` Jarkko Sakkinen
2019-05-21 15:51                                                                     ` Sean Christopherson
2019-05-22 13:20                                                                       ` Jarkko Sakkinen
2019-05-22 13:22                                                                         ` Jarkko Sakkinen
2019-05-22 13:56                                                                           ` Stephen Smalley
2019-05-22 15:38                                                                             ` Sean Christopherson
2019-05-22 22:42                                                                               ` Andy Lutomirski
2019-05-23  2:35                                                                                 ` Sean Christopherson
2019-05-23 10:26                                                                                   ` Jarkko Sakkinen
2019-05-23 14:17                                                                                     ` Sean Christopherson
2019-05-23 15:38                                                                                       ` Andy Lutomirski
2019-05-23 23:40                                                                                         ` Sean Christopherson
2019-05-24  1:17                                                                                           ` Andy Lutomirski
2019-05-24  7:24                                                                                             ` Xing, Cedric
2019-05-24 15:41                                                                                               ` Stephen Smalley
2019-05-24 16:57                                                                                                 ` Xing, Cedric
2019-05-24 17:42                                                                                                 ` Sean Christopherson
2019-05-24 17:54                                                                                                   ` Andy Lutomirski
2019-05-24 17:56                                                                                                     ` Sean Christopherson
2019-05-24 17:54                                                                                                   ` Sean Christopherson
2019-05-24 18:34                                                                                                     ` Xing, Cedric
2019-05-24 19:13                                                                                                       ` Sean Christopherson
2019-05-24 19:30                                                                                                         ` Andy Lutomirski
2019-05-24 20:42                                                                                                         ` Xing, Cedric
2019-05-24 21:11                                                                                                           ` Sean Christopherson
2019-05-24 19:37                                                                                                       ` Andy Lutomirski
2019-05-24 20:03                                                                                                         ` Sean Christopherson
2019-05-24 20:58                                                                                                           ` Xing, Cedric
2019-05-24 21:27                                                                                                           ` Andy Lutomirski
2019-05-24 22:41                                                                                                             ` Sean Christopherson
2019-05-24 23:42                                                                                                               ` Andy Lutomirski
2019-05-25 22:40                                                                                                                 ` Xing, Cedric
2019-05-26  0:57                                                                                                                   ` Andy Lutomirski
2019-05-26  6:09                                                                                                                     ` Xing, Cedric
2019-05-28 20:24                                                                                                                       ` Sean Christopherson
2019-05-28 20:48                                                                                                                         ` Andy Lutomirski
2019-05-28 21:41                                                                                                                           ` Sean Christopherson
2019-05-30  5:38                                                                                                                             ` Xing, Cedric
2019-05-30 17:21                                                                                                                               ` Sean Christopherson
2019-05-29 14:08                                                                                                                         ` Stephen Smalley
2019-05-30  6:12                                                                                                                           ` Xing, Cedric
2019-05-30 14:22                                                                                                                             ` Stephen Smalley
2019-05-30 14:31                                                                                                                               ` Andy Lutomirski
2019-05-30 15:04                                                                                                                                 ` Stephen Smalley
2019-05-30 16:14                                                                                                                                   ` Andy Lutomirski
2019-05-30 18:01                                                                                                                                     ` Sean Christopherson
2019-05-30 19:20                                                                                                                                       ` Andy Lutomirski
2019-05-30 21:16                                                                                                                                         ` Sean Christopherson
2019-05-30 21:23                                                                                                                                           ` Andy Lutomirski
2019-05-30 21:36                                                                                                                                             ` Sean Christopherson
2019-06-03  9:12                                                                                                                                               ` Dr. Greg
2019-06-03 21:08                                                                                                                                               ` Jarkko Sakkinen
2019-05-30 21:48                                                                                                                                         ` Xing, Cedric
2019-05-30 22:24                                                                                                                                           ` Sean Christopherson
2019-06-03 21:05                                                                                                                                       ` Jarkko Sakkinen
2019-06-03 20:54                                                                                                                                     ` Jarkko Sakkinen
2019-06-03 21:23                                                                                                                                       ` Sean Christopherson
2019-06-04 11:39                                                                                                                                         ` Jarkko Sakkinen
2019-06-03 21:37                                                                                                                                       ` Andy Lutomirski
2019-06-03 20:47                                                                                                                                   ` Jarkko Sakkinen
2019-06-03 20:43                                                                                                                                 ` Jarkko Sakkinen
2019-05-25 17:31                                                                                                           ` Dr. Greg
2019-05-24 16:43                                                                                               ` Andy Lutomirski
2019-05-24 17:07                                                                                                 ` Sean Christopherson
2019-05-24 17:51                                                                                                   ` Andy Lutomirski
2019-05-24 14:44                                                                                         ` Stephen Smalley
2019-05-27 13:48                                                                                         ` Jarkko Sakkinen
2019-05-23 19:58                                                                                       ` Sean Christopherson
2019-05-27 13:34                                                                                       ` Jarkko Sakkinen
2019-05-27 13:38                                                                                         ` Jarkko Sakkinen
2019-05-23  8:10                                                                                 ` Jarkko Sakkinen
2019-05-23  8:23                                                                                   ` Jarkko Sakkinen
2019-05-20 11:36                                                               ` Jarkko Sakkinen
2019-05-15 10:35                                                       ` [PATCH v20 00/28] Intel SGX1 support Jarkko Sakkinen
2019-05-15 11:00                                                         ` Jarkko Sakkinen
2019-05-15 14:27                                                           ` Andy Lutomirski
2019-05-16  5:07                                                             ` Jarkko Sakkinen
2019-05-16  6:51                                                               ` Jarkko Sakkinen
2019-05-16  7:02                                                                 ` Jarkko Sakkinen
2019-05-15 13:21                                                         ` Sean Christopherson
2019-05-16  5:01                                                           ` Jarkko Sakkinen
2019-05-15  8:49                                                     ` Jarkko Sakkinen
2019-05-15  9:58                                                       ` Jarkko Sakkinen
2019-05-14 14:33                                               ` Haitao Huang
2019-05-14 15:17                                                 ` Andy Lutomirski
2019-05-14 15:30                                                   ` Haitao Huang
2019-05-14 20:45                                                     ` Andy Lutomirski
2019-05-14 21:08                                                       ` Haitao Huang
2019-05-14 21:58                                                       ` Xing, Cedric
2019-05-15  5:15                                                         ` Haitao Huang
2019-05-10 18:44                                       ` Xing, Cedric
2019-04-19 21:34                       ` Thomas Gleixner
2019-04-19 21:05               ` Jethro Beekman
2019-04-18 18:07   ` Andy Lutomirski
2019-04-22 20:42 ` [RFC PATCH v1 0/3] An alternative __vdso_sgx_enter_enclave() to allow enclave/host parameter passing using untrusted stack Cedric Xing
2019-04-22 22:05   ` Sean Christopherson
2019-04-23  0:37   ` Cedric Xing
2019-04-24  6:26   ` [RFC PATCH v2 " Cedric Xing
2019-07-10 11:17     ` Jarkko Sakkinen
2019-07-10 18:08       ` Xing, Cedric
2019-07-10 22:46         ` Jarkko Sakkinen
2019-07-10 22:54           ` Xing, Cedric
2019-07-11  9:36             ` Jarkko Sakkinen
2019-07-11 19:49               ` Xing, Cedric
2019-07-10 23:15           ` Jarkko Sakkinen
2019-07-10 23:37             ` Xing, Cedric
2019-07-11  9:38               ` Jarkko Sakkinen
2019-07-11 15:50                 ` Sean Christopherson
2019-07-11 17:59                   ` Jarkko Sakkinen
2019-07-11 19:51                 ` Xing, Cedric
2019-07-11  4:21     ` [RFC PATCH v3 0/3] x86/sgx: Amend vDSO API to allow enclave/host parameter passing on " Cedric Xing
2019-07-12  3:28       ` Jarkko Sakkinen
2019-07-13  6:51       ` [RFC PATCH v4 " Cedric Xing
2019-07-13  6:51       ` [RFC PATCH v4 1/3] selftests/x86/sgx: Fix Makefile for SGX selftest Cedric Xing
2019-07-13 15:10         ` Jarkko Sakkinen
2019-07-13 15:15           ` Jarkko Sakkinen
2019-07-13 17:29             ` Xing, Cedric
2019-07-14 14:53               ` Jarkko Sakkinen
2019-07-13  6:51       ` [RFC PATCH v4 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-07-13 15:04         ` Jarkko Sakkinen
2019-07-13 15:06           ` Jarkko Sakkinen
2019-07-13  6:51       ` [RFC PATCH v4 3/3] selftests/x86/sgx: Augment SGX selftest to test vDSO API Cedric Xing
2019-07-13 15:21         ` Jarkko Sakkinen
2019-07-13 17:20           ` Xing, Cedric
2019-07-14 14:40             ` Jarkko Sakkinen
2019-07-14 14:47             ` Jarkko Sakkinen
2019-07-17 21:57               ` Xing, Cedric
2019-07-11  4:21     ` [RFC PATCH v3 1/3] selftests/x86: Fixed Makefile for SGX selftest Cedric Xing
2019-07-11  4:21     ` [RFC PATCH v3 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-07-11  9:50       ` Jarkko Sakkinen
2019-07-11  9:53       ` Jarkko Sakkinen
2019-07-11 15:42         ` Sean Christopherson
2019-07-11 17:55           ` Jarkko Sakkinen
2019-07-11 17:58             ` Sean Christopherson
2019-07-12  3:16               ` Jarkko Sakkinen
2019-07-13  7:00                 ` Xing, Cedric
2019-07-11  4:21     ` [RFC PATCH v3 3/3] selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface Cedric Xing
2019-04-24  6:26   ` [RFC PATCH v2 1/3] selftests/x86: Fixed Makefile for SGX selftest Cedric Xing
2019-07-12  3:19     ` Jarkko Sakkinen
2019-07-13  6:58       ` Xing, Cedric
2019-04-24  6:26   ` [RFC PATCH v2 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-04-24 19:04     ` Sean Christopherson
2019-04-25 23:31       ` Xing, Cedric [this message]
2019-04-26 21:00         ` Sean Christopherson
2019-05-02  8:28           ` Jarkko Sakkinen
2019-04-24  6:26   ` [RFC PATCH v2 3/3] selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface Cedric Xing
2019-07-12  3:25     ` Jarkko Sakkinen
2019-07-13  7:03       ` Xing, Cedric
2019-04-22 20:42 ` [RFC PATCH v1 1/3] selftests/x86: Fixed Makefile for SGX selftest Cedric Xing
2019-04-23  0:37   ` Cedric Xing
2019-04-22 20:42 ` [RFC PATCH v1 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack Cedric Xing
2019-04-22 22:26   ` Sean Christopherson
2019-04-23  0:37   ` Cedric Xing
2019-04-23  1:25   ` Andy Lutomirski
2019-04-24 17:56     ` Xing, Cedric
2019-04-23 19:26   ` Sean Christopherson
2019-04-23 19:44     ` Andy Lutomirski
2019-04-22 20:42 ` [RFC PATCH v1 3/3] selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface Cedric Xing
2019-04-23  0:37   ` Cedric Xing
2019-04-23  1:29   ` Andy Lutomirski
2019-04-23  1:48     ` Sean Christopherson
2019-04-23 18:59     ` Sean Christopherson
2019-04-23 19:07       ` Andy Lutomirski
2019-04-23 20:11         ` Sean Christopherson
2019-04-23 11:56 ` [PATCH v20 00/28] Intel SGX1 support Jarkko Sakkinen
2019-04-23 16:52   ` Andy Lutomirski
2019-04-24 12:17     ` Jarkko Sakkinen
2019-05-08 13:45       ` Jarkko Sakkinen

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=960B34DE67B9E140824F1DCDEC400C0F4E87FD17@ORSMSX116.amr.corp.intel.com \
    --to=cedric.xing@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Sgx Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \
		linux-sgx@vger.kernel.org linux-sgx@archiver.kernel.org
	public-inbox-index linux-sgx


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx


AGPL code for this site: git clone https://public-inbox.org/ public-inbox