From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@kernel.org>, Jann Horn <jannh@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Rich Felker <dalias@libc.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jethro Beekman <jethro@fortanix.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Florian Weimer <fweimer@redhat.com>,
Linux API <linux-api@vger.kernel.org>, X86 ML <x86@kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
nhorman@redhat.com, npmccallum@redhat.com, "Ayoun,
Serge" <serge.ayoun@intel.com>,
shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>I
Subject: Re: RFC: userspace exception fixups
Date: Thu, 8 Nov 2018 11:54:20 -0800 [thread overview]
Message-ID: <20181108195420.GA14715@linux.intel.com> (raw)
In-Reply-To: <9B76E95B-5745-412E-8007-7FAA7F83D6FB@amacapital.net>
On Tue, Nov 06, 2018 at 01:07:54PM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 6, 2018, at 1:00 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> >
> >> On 11/6/18 12:12 PM, Andy Lutomirski wrote:
> >> True, but what if we have a nasty enclave that writes to memory just
> >> below SP *before* decrementing SP?
> >
> > Yeah, that would be unfortunate. If an enclave did this (roughly):
> >
> > 1. EENTER
> > 2. Hardware sets eenter_hwframe->sp = %sp
> > 3. Enclave runs... wants to do out-call
> > 4. Enclave sets up parameters:
> > memcpy(&eenter_hwframe->sp[-offset], arg1, size);
> > ...
> > 5. Enclave sets eenter_hwframe->sp -= offset
> >
> > If we got a signal between 4 and 5, we'd clobber the copy of 'arg1' that
> > was on the stack. The enclave could easily fix this by moving ->sp first.
> >
> > But, this is one of those "fun" parts of the ABI that I think we need to
> > talk about. If we do this, we also basically require that the code
> > which handles asynchronous exits must *not* write to the stack. That's
> > not hard because it's typically just a single ERESUME instruction, but
> > it *is* a requirement.
> >
>
> I was assuming that the async exit stuff was completely hidden by the
> API. The AEP code would decide whether the exit got fixed up by the
> kernel (which may or may not be easy to tell — can the code even tell
> without kernel help whether it was, say, an IRQ vs #UD?) and then either
> do ERESUME or cause sgx_enter_enclave() to return with an appropriate
> return value.
Ok, SDK folks came up with an idea that would allow them to use vDSO,
albeit with a bit of ugliness and potentially a ROP-attack issue.
Definitely some weirdness, but the weirdness is well contained, unlike
the magic prefix approach.
Provide two enter_enclave() vDSO "functions". The first is a normal
function with a normal C interface. The second is a blob of code that
is "called" and "returns" via indirect jmp, and can be used by SGX
runtimes that want to use the untrusted stack for out-calls from the
enclave.
For the indirect jmp "function", use %rbp to stash the return address
of the caller (either in %rbp itself or in memory pointed to by %rbp).
It works because hardware also saves/restores %rbp along with %rsp when
doing enclave transitions, and the SDK can live with %rbp being
off-limits. Fault info is passed via registers.
Basic idea for the "functions" below. The fixup stuff is obviously not
wired up correctly, just trying to convey the concept.
struct enclu_fault_info {
unsigned int leaf;
unsigned int trapnr;
unsigned int error_code;
unsigned long address;
};
int __vdso_enter_enclave(void *tcs, struct enclu_fault_info *fault_info)
{
unsigned int leaf, trapnr;
asm volatile (
"lea 2f(%%rip), %%rcx\n\t"
"1: enclu\n\t"
"jmp 3f\n\t"
/* ERESUME trampoline */
"2: enclu\n\t"
"ud2\n\t"
/* out: */
"3:\n"
/* EENTER fixup */
".pushsection .fixup,\"ax\"\n\t"
"4:\n\t"
"mov %%eax, %%edi\n\t"
"movl $"__stringify(SGX_EENTER)", %%eax\n\t"
"jmp 3b\n\t"
".popsection\n\t"
_ASM_EXTABLE_FAULT(1b, 4b)
/* ERESUME FIXUP */
".pushsection .fixup,\"ax\"\n\t"
"5:\n\t"
"mov %%eax, %%edi\n\t"
"movl $"__stringify(SGX_ERESUME)", %%eax\n\t"
"jmp 3b\n\t"
".popsection\n\t"
_ASM_EXTABLE_FAULT(2b, 5b)
: "=a"(leaf), "=D" (trapnr)
: "a" (SGX_EENTER), "b" (tcs)
: "cc", "memory", "rcx", "rdx", "rsi", "r8", "r9", "r10",
"r11", "r12", "r13", "r14", "r15"
);
if (leaf == SGX_EEXIT)
return 0;
if (fault_info) {
fault_info->leaf = leaf;
fault_info->trapnr = trapnr;
fault_info->error_code = 0;
fault_info->address = 0;
}
return -EFAULT;
}
GLOBAL(__vdso_enter_enclave_no_stack)
endbr64
/* %rbp = return target, %rbx = tcs */
leaq 3f(%rip), %rcx
movl $2, %eax
1: enclu
/* "return" to "caller" */
2: jmp *%rbp
/* ERESUME trampoline */
3: enclu
ud2
/* EENTER fixup handler */
4: movq %rax, %rdi
movl $2, %eax
/* %rsi = error code, %rdx = address */
jmp 2b
/* ERESUME fixup handler */
5: movq %rax, %rdi
movl $3, %eax
/* %rsi = error code, %rdx = address */
jmp 2b
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@kernel.org>, Jann Horn <jannh@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Rich Felker <dalias@libc.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jethro Beekman <jethro@fortanix.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Florian Weimer <fweimer@redhat.com>,
Linux API <linux-api@vger.kernel.org>, X86 ML <x86@kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
nhorman@redhat.com, npmccallum@redhat.com, "Ayoun,
Serge" <serge.ayoun@intel.com>,
shay.katz-zamir@intel.com, linux-sgx@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Carlos O'Donell <carlos@redhat.com>,
adhemerval.zanella@linaro.org
Subject: Re: RFC: userspace exception fixups
Date: Thu, 8 Nov 2018 11:54:20 -0800 [thread overview]
Message-ID: <20181108195420.GA14715@linux.intel.com> (raw)
Message-ID: <20181108195420.sBeq-z44IJf_LjsBvmZQH7xyGQtk3_PEWZ5LbQR7Zhg@z> (raw)
In-Reply-To: <9B76E95B-5745-412E-8007-7FAA7F83D6FB@amacapital.net>
On Tue, Nov 06, 2018 at 01:07:54PM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 6, 2018, at 1:00 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> >
> >> On 11/6/18 12:12 PM, Andy Lutomirski wrote:
> >> True, but what if we have a nasty enclave that writes to memory just
> >> below SP *before* decrementing SP?
> >
> > Yeah, that would be unfortunate. If an enclave did this (roughly):
> >
> > 1. EENTER
> > 2. Hardware sets eenter_hwframe->sp = %sp
> > 3. Enclave runs... wants to do out-call
> > 4. Enclave sets up parameters:
> > memcpy(&eenter_hwframe->sp[-offset], arg1, size);
> > ...
> > 5. Enclave sets eenter_hwframe->sp -= offset
> >
> > If we got a signal between 4 and 5, we'd clobber the copy of 'arg1' that
> > was on the stack. The enclave could easily fix this by moving ->sp first.
> >
> > But, this is one of those "fun" parts of the ABI that I think we need to
> > talk about. If we do this, we also basically require that the code
> > which handles asynchronous exits must *not* write to the stack. That's
> > not hard because it's typically just a single ERESUME instruction, but
> > it *is* a requirement.
> >
>
> I was assuming that the async exit stuff was completely hidden by the
> API. The AEP code would decide whether the exit got fixed up by the
> kernel (which may or may not be easy to tell — can the code even tell
> without kernel help whether it was, say, an IRQ vs #UD?) and then either
> do ERESUME or cause sgx_enter_enclave() to return with an appropriate
> return value.
Ok, SDK folks came up with an idea that would allow them to use vDSO,
albeit with a bit of ugliness and potentially a ROP-attack issue.
Definitely some weirdness, but the weirdness is well contained, unlike
the magic prefix approach.
Provide two enter_enclave() vDSO "functions". The first is a normal
function with a normal C interface. The second is a blob of code that
is "called" and "returns" via indirect jmp, and can be used by SGX
runtimes that want to use the untrusted stack for out-calls from the
enclave.
For the indirect jmp "function", use %rbp to stash the return address
of the caller (either in %rbp itself or in memory pointed to by %rbp).
It works because hardware also saves/restores %rbp along with %rsp when
doing enclave transitions, and the SDK can live with %rbp being
off-limits. Fault info is passed via registers.
Basic idea for the "functions" below. The fixup stuff is obviously not
wired up correctly, just trying to convey the concept.
struct enclu_fault_info {
unsigned int leaf;
unsigned int trapnr;
unsigned int error_code;
unsigned long address;
};
int __vdso_enter_enclave(void *tcs, struct enclu_fault_info *fault_info)
{
unsigned int leaf, trapnr;
asm volatile (
"lea 2f(%%rip), %%rcx\n\t"
"1: enclu\n\t"
"jmp 3f\n\t"
/* ERESUME trampoline */
"2: enclu\n\t"
"ud2\n\t"
/* out: */
"3:\n"
/* EENTER fixup */
".pushsection .fixup,\"ax\"\n\t"
"4:\n\t"
"mov %%eax, %%edi\n\t"
"movl $"__stringify(SGX_EENTER)", %%eax\n\t"
"jmp 3b\n\t"
".popsection\n\t"
_ASM_EXTABLE_FAULT(1b, 4b)
/* ERESUME FIXUP */
".pushsection .fixup,\"ax\"\n\t"
"5:\n\t"
"mov %%eax, %%edi\n\t"
"movl $"__stringify(SGX_ERESUME)", %%eax\n\t"
"jmp 3b\n\t"
".popsection\n\t"
_ASM_EXTABLE_FAULT(2b, 5b)
: "=a"(leaf), "=D" (trapnr)
: "a" (SGX_EENTER), "b" (tcs)
: "cc", "memory", "rcx", "rdx", "rsi", "r8", "r9", "r10",
"r11", "r12", "r13", "r14", "r15"
);
if (leaf == SGX_EEXIT)
return 0;
if (fault_info) {
fault_info->leaf = leaf;
fault_info->trapnr = trapnr;
fault_info->error_code = 0;
fault_info->address = 0;
}
return -EFAULT;
}
GLOBAL(__vdso_enter_enclave_no_stack)
endbr64
/* %rbp = return target, %rbx = tcs */
leaq 3f(%rip), %rcx
movl $2, %eax
1: enclu
/* "return" to "caller" */
2: jmp *%rbp
/* ERESUME trampoline */
3: enclu
ud2
/* EENTER fixup handler */
4: movq %rax, %rdi
movl $2, %eax
/* %rsi = error code, %rdx = address */
jmp 2b
/* ERESUME fixup handler */
5: movq %rax, %rdi
movl $3, %eax
/* %rsi = error code, %rdx = address */
jmp 2b
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@kernel.org>, Jann Horn <jannh@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Rich Felker <dalias@libc.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jethro Beekman <jethro@fortanix.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Florian Weimer <fweimer@redhat.com>,
Linux API <linux-api@vger.kernel.org>, X86 ML <x86@kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>, <nhorman@redhat.com>,
<npmccallum@redhat.com>, "Ayoun, Serge" <serge.ayoun@intel.com>,
<shay.katz-zamir@intel.com>, <linux-sgx@vger.kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"Carlos O'Donell" <carlos@redhat.com>,
<adhemerval.zanella@linaro.org>
Subject: Re: RFC: userspace exception fixups
Date: Thu, 8 Nov 2018 11:54:20 -0800 [thread overview]
Message-ID: <20181108195420.GA14715@linux.intel.com> (raw)
In-Reply-To: <9B76E95B-5745-412E-8007-7FAA7F83D6FB@amacapital.net>
On Tue, Nov 06, 2018 at 01:07:54PM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 6, 2018, at 1:00 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> >
> >> On 11/6/18 12:12 PM, Andy Lutomirski wrote:
> >> True, but what if we have a nasty enclave that writes to memory just
> >> below SP *before* decrementing SP?
> >
> > Yeah, that would be unfortunate. If an enclave did this (roughly):
> >
> > 1. EENTER
> > 2. Hardware sets eenter_hwframe->sp = %sp
> > 3. Enclave runs... wants to do out-call
> > 4. Enclave sets up parameters:
> > memcpy(&eenter_hwframe->sp[-offset], arg1, size);
> > ...
> > 5. Enclave sets eenter_hwframe->sp -= offset
> >
> > If we got a signal between 4 and 5, we'd clobber the copy of 'arg1' that
> > was on the stack. The enclave could easily fix this by moving ->sp first.
> >
> > But, this is one of those "fun" parts of the ABI that I think we need to
> > talk about. If we do this, we also basically require that the code
> > which handles asynchronous exits must *not* write to the stack. That's
> > not hard because it's typically just a single ERESUME instruction, but
> > it *is* a requirement.
> >
>
> I was assuming that the async exit stuff was completely hidden by the
> API. The AEP code would decide whether the exit got fixed up by the
> kernel (which may or may not be easy to tell — can the code even tell
> without kernel help whether it was, say, an IRQ vs #UD?) and then either
> do ERESUME or cause sgx_enter_enclave() to return with an appropriate
> return value.
Ok, SDK folks came up with an idea that would allow them to use vDSO,
albeit with a bit of ugliness and potentially a ROP-attack issue.
Definitely some weirdness, but the weirdness is well contained, unlike
the magic prefix approach.
Provide two enter_enclave() vDSO "functions". The first is a normal
function with a normal C interface. The second is a blob of code that
is "called" and "returns" via indirect jmp, and can be used by SGX
runtimes that want to use the untrusted stack for out-calls from the
enclave.
For the indirect jmp "function", use %rbp to stash the return address
of the caller (either in %rbp itself or in memory pointed to by %rbp).
It works because hardware also saves/restores %rbp along with %rsp when
doing enclave transitions, and the SDK can live with %rbp being
off-limits. Fault info is passed via registers.
Basic idea for the "functions" below. The fixup stuff is obviously not
wired up correctly, just trying to convey the concept.
struct enclu_fault_info {
unsigned int leaf;
unsigned int trapnr;
unsigned int error_code;
unsigned long address;
};
int __vdso_enter_enclave(void *tcs, struct enclu_fault_info *fault_info)
{
unsigned int leaf, trapnr;
asm volatile (
"lea 2f(%%rip), %%rcx\n\t"
"1: enclu\n\t"
"jmp 3f\n\t"
/* ERESUME trampoline */
"2: enclu\n\t"
"ud2\n\t"
/* out: */
"3:\n"
/* EENTER fixup */
".pushsection .fixup,\"ax\"\n\t"
"4:\n\t"
"mov %%eax, %%edi\n\t"
"movl $"__stringify(SGX_EENTER)", %%eax\n\t"
"jmp 3b\n\t"
".popsection\n\t"
_ASM_EXTABLE_FAULT(1b, 4b)
/* ERESUME FIXUP */
".pushsection .fixup,\"ax\"\n\t"
"5:\n\t"
"mov %%eax, %%edi\n\t"
"movl $"__stringify(SGX_ERESUME)", %%eax\n\t"
"jmp 3b\n\t"
".popsection\n\t"
_ASM_EXTABLE_FAULT(2b, 5b)
: "=a"(leaf), "=D" (trapnr)
: "a" (SGX_EENTER), "b" (tcs)
: "cc", "memory", "rcx", "rdx", "rsi", "r8", "r9", "r10",
"r11", "r12", "r13", "r14", "r15"
);
if (leaf == SGX_EEXIT)
return 0;
if (fault_info) {
fault_info->leaf = leaf;
fault_info->trapnr = trapnr;
fault_info->error_code = 0;
fault_info->address = 0;
}
return -EFAULT;
}
GLOBAL(__vdso_enter_enclave_no_stack)
endbr64
/* %rbp = return target, %rbx = tcs */
leaq 3f(%rip), %rcx
movl $2, %eax
1: enclu
/* "return" to "caller" */
2: jmp *%rbp
/* ERESUME trampoline */
3: enclu
ud2
/* EENTER fixup handler */
4: movq %rax, %rdi
movl $2, %eax
/* %rsi = error code, %rdx = address */
jmp 2b
/* ERESUME fixup handler */
5: movq %rax, %rdi
movl $3, %eax
/* %rsi = error code, %rdx = address */
jmp 2b
next prev parent reply other threads:[~2018-11-08 19:54 UTC|newest]
Thread overview: 235+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 17:53 RFC: userspace exception fixups Andy Lutomirski
2018-11-01 17:53 ` Andy Lutomirski
2018-11-01 17:53 ` Andy Lutomirski
2018-11-01 18:09 ` Florian Weimer
2018-11-01 18:09 ` Florian Weimer
2018-11-01 18:09 ` Florian Weimer
2018-11-01 18:09 ` Florian Weimer
2018-11-01 18:30 ` Rich Felker
2018-11-01 18:30 ` Rich Felker
2018-11-01 18:30 ` Rich Felker
2018-11-01 19:00 ` Jarkko Sakkinen
2018-11-01 19:00 ` Jarkko Sakkinen
2018-11-01 19:00 ` Jarkko Sakkinen
2018-11-01 18:27 ` Rich Felker
2018-11-01 18:27 ` Rich Felker
2018-11-01 18:27 ` Rich Felker
2018-11-01 18:33 ` Jann Horn
2018-11-01 18:33 ` Jann Horn
2018-11-01 18:52 ` Rich Felker
2018-11-01 18:52 ` Rich Felker
2018-11-01 19:10 ` Linus Torvalds
2018-11-01 19:10 ` Linus Torvalds
2018-11-01 19:31 ` Rich Felker
2018-11-01 19:31 ` Rich Felker
2018-11-01 21:24 ` Linus Torvalds
2018-11-01 21:24 ` Linus Torvalds
2018-11-01 23:22 ` Andy Lutomirski
2018-11-01 23:22 ` Andy Lutomirski
2018-11-01 23:22 ` Andy Lutomirski
2018-11-02 16:30 ` Sean Christopherson
2018-11-02 16:30 ` Sean Christopherson
2018-11-02 16:30 ` Sean Christopherson
2018-11-02 16:37 ` Jethro Beekman
2018-11-02 16:37 ` Jethro Beekman
2018-11-02 16:52 ` Sean Christopherson
2018-11-02 16:52 ` Sean Christopherson
2018-11-02 16:56 ` Jethro Beekman
2018-11-02 16:56 ` Jethro Beekman
2018-11-02 17:01 ` Andy Lutomirski
2018-11-02 17:01 ` Andy Lutomirski
2018-11-02 17:01 ` Andy Lutomirski
2018-11-02 17:05 ` Jethro Beekman
2018-11-02 17:05 ` Jethro Beekman
2018-11-02 17:16 ` Andy Lutomirski
2018-11-02 17:16 ` Andy Lutomirski
2018-11-02 17:16 ` Andy Lutomirski
2018-11-02 17:32 ` Rich Felker
2018-11-02 17:32 ` Rich Felker
2018-11-02 17:32 ` Rich Felker
2018-11-02 17:12 ` Sean Christopherson
2018-11-02 17:12 ` Sean Christopherson
2018-11-02 22:42 ` Jarkko Sakkinen
2018-11-02 22:42 ` Jarkko Sakkinen
2018-11-02 16:56 ` Dave Hansen
2018-11-02 16:56 ` Dave Hansen
2018-11-02 16:56 ` Dave Hansen
2018-11-02 17:06 ` Sean Christopherson
2018-11-02 17:06 ` Sean Christopherson
2018-11-02 17:06 ` Sean Christopherson
2018-11-02 17:13 ` Dave Hansen
2018-11-02 17:13 ` Dave Hansen
2018-11-02 17:13 ` Dave Hansen
2018-11-02 17:33 ` Sean Christopherson
2018-11-02 17:33 ` Sean Christopherson
2018-11-02 17:33 ` Sean Christopherson
2018-11-02 17:48 ` Andy Lutomirski
2018-11-02 17:48 ` Andy Lutomirski
2018-11-02 17:48 ` Andy Lutomirski
2018-11-02 18:27 ` Sean Christopherson
2018-11-02 18:27 ` Sean Christopherson
2018-11-02 18:27 ` Sean Christopherson
2018-11-02 19:02 ` Jann Horn
2018-11-02 19:02 ` Jann Horn
2018-11-02 19:02 ` Jann Horn
2018-11-02 22:04 ` Sean Christopherson
2018-11-02 22:04 ` Sean Christopherson
2018-11-02 22:04 ` Sean Christopherson
2018-11-02 23:27 ` Jann Horn
2018-11-02 23:27 ` Jann Horn
2018-11-02 23:27 ` Jann Horn
2018-11-02 23:32 ` Andy Lutomirski
2018-11-02 23:32 ` Andy Lutomirski
2018-11-02 23:32 ` Andy Lutomirski
2018-11-02 23:36 ` Jann Horn
2018-11-02 23:36 ` Jann Horn
2018-11-02 23:36 ` Jann Horn
2018-11-06 15:37 ` Sean Christopherson
2018-11-06 15:37 ` Sean Christopherson
2018-11-06 15:37 ` Sean Christopherson
2018-11-06 16:57 ` Andy Lutomirski
2018-11-06 16:57 ` Andy Lutomirski
2018-11-06 16:57 ` Andy Lutomirski
2018-11-06 17:03 ` Dave Hansen
2018-11-06 17:03 ` Dave Hansen
2018-11-06 17:03 ` Dave Hansen
2018-11-06 17:19 ` Sean Christopherson
2018-11-06 17:19 ` Sean Christopherson
2018-11-06 17:19 ` Sean Christopherson
2018-11-06 18:20 ` Andy Lutomirski
2018-11-06 18:20 ` Andy Lutomirski
2018-11-06 18:20 ` Andy Lutomirski
2018-11-06 18:41 ` Dave Hansen
2018-11-06 18:41 ` Dave Hansen
2018-11-06 18:41 ` Dave Hansen
2018-11-06 19:02 ` Andy Lutomirski
2018-11-06 19:02 ` Andy Lutomirski
2018-11-06 19:02 ` Andy Lutomirski
2018-11-06 19:22 ` Dave Hansen
2018-11-06 19:22 ` Dave Hansen
2018-11-06 19:22 ` Dave Hansen
2018-11-06 20:12 ` Andy Lutomirski
2018-11-06 20:12 ` Andy Lutomirski
2018-11-06 20:12 ` Andy Lutomirski
2018-11-06 21:00 ` Dave Hansen
2018-11-06 21:00 ` Dave Hansen
2018-11-06 21:00 ` Dave Hansen
2018-11-06 21:07 ` Andy Lutomirski
2018-11-06 21:07 ` Andy Lutomirski
2018-11-06 21:07 ` Andy Lutomirski
2018-11-06 21:41 ` Andy Lutomirski
2018-11-06 21:41 ` Andy Lutomirski
2018-11-06 21:41 ` Andy Lutomirski
2018-11-06 21:59 ` Sean Christopherson
2018-11-06 21:59 ` Sean Christopherson
2018-11-06 21:59 ` Sean Christopherson
2018-11-06 23:00 ` Andy Lutomirski
2018-11-06 23:00 ` Andy Lutomirski
2018-11-06 23:00 ` Andy Lutomirski
2018-11-06 23:35 ` Sean Christopherson
2018-11-06 23:35 ` Sean Christopherson
2018-11-06 23:35 ` Sean Christopherson
2018-11-06 23:39 ` Andy Lutomirski
2018-11-06 23:39 ` Andy Lutomirski
2018-11-06 23:39 ` Andy Lutomirski
2018-11-07 0:02 ` Sean Christopherson
2018-11-07 0:02 ` Sean Christopherson
2018-11-07 0:02 ` Sean Christopherson
2018-11-07 1:17 ` Andy Lutomirski
2018-11-07 1:17 ` Andy Lutomirski
2018-11-07 1:17 ` Andy Lutomirski
2018-11-07 6:47 ` Jethro Beekman
2018-11-07 6:47 ` Jethro Beekman
2018-11-07 15:34 ` Sean Christopherson
2018-11-07 15:34 ` Sean Christopherson
2018-11-07 15:34 ` Sean Christopherson
2018-11-07 19:01 ` Sean Christopherson
2018-11-07 19:01 ` Sean Christopherson
2018-11-07 19:01 ` Sean Christopherson
2018-11-07 20:56 ` Dave Hansen
2018-11-07 20:56 ` Dave Hansen
2018-11-07 20:56 ` Dave Hansen
2018-11-08 15:04 ` Jarkko Sakkinen
2018-11-08 15:04 ` Jarkko Sakkinen
2018-11-08 15:04 ` Jarkko Sakkinen
2018-11-08 19:54 ` Sean Christopherson [this message]
2018-11-08 19:54 ` Sean Christopherson
2018-11-08 19:54 ` Sean Christopherson
2018-11-08 20:05 ` Andy Lutomirski
2018-11-08 20:05 ` Andy Lutomirski
2018-11-08 20:05 ` Andy Lutomirski
2018-11-08 20:10 ` Dave Hansen
2018-11-08 20:10 ` Dave Hansen
2018-11-08 20:10 ` Dave Hansen
2018-11-08 21:16 ` Sean Christopherson
2018-11-08 21:16 ` Sean Christopherson
2018-11-08 21:16 ` Sean Christopherson
2018-11-08 21:50 ` Dave Hansen
2018-11-08 21:50 ` Dave Hansen
2018-11-08 21:50 ` Dave Hansen
2018-11-08 22:04 ` Sean Christopherson
2018-11-08 22:04 ` Sean Christopherson
2018-11-08 22:04 ` Sean Christopherson
2018-11-09 7:12 ` Christoph Hellwig
2018-11-09 7:12 ` Christoph Hellwig
2018-11-09 7:12 ` Christoph Hellwig
2018-11-06 23:17 ` Rich Felker
2018-11-06 23:17 ` Rich Felker
2018-11-06 23:17 ` Rich Felker
2018-11-06 23:26 ` Sean Christopherson
2018-11-06 23:26 ` Sean Christopherson
2018-11-06 23:26 ` Sean Christopherson
2018-11-07 21:27 ` Rich Felker
2018-11-07 21:27 ` Rich Felker
2018-11-07 21:27 ` Rich Felker
2018-11-07 21:33 ` Andy Lutomirski
2018-11-07 21:33 ` Andy Lutomirski
2018-11-07 21:33 ` Andy Lutomirski
2018-11-07 21:40 ` Sean Christopherson
2018-11-07 21:40 ` Sean Christopherson
2018-11-07 21:40 ` Sean Christopherson
2018-11-08 15:11 ` Jarkko Sakkinen
2018-11-08 15:11 ` Jarkko Sakkinen
2018-11-08 15:11 ` Jarkko Sakkinen
2018-11-06 17:00 ` Dave Hansen
2018-11-06 17:00 ` Dave Hansen
2018-11-06 17:00 ` Dave Hansen
2018-11-02 22:37 ` Jarkko Sakkinen
2018-11-02 22:37 ` Jarkko Sakkinen
2018-11-02 22:37 ` Jarkko Sakkinen
2018-11-01 19:06 ` Linus Torvalds
2018-11-01 19:06 ` Linus Torvalds
2018-11-02 22:07 ` Jarkko Sakkinen
2018-11-02 22:07 ` Jarkko Sakkinen
2018-11-18 7:15 ` Jarkko Sakkinen
2018-11-18 7:18 ` Jarkko Sakkinen
2018-11-18 13:02 ` Jarkko Sakkinen
2018-11-18 13:02 ` Jarkko Sakkinen
2018-11-18 13:02 ` Jarkko Sakkinen
2018-11-19 5:17 ` Jethro Beekman
2018-11-19 5:17 ` Jethro Beekman
2018-11-19 14:05 ` Jarkko Sakkinen
2018-11-19 14:05 ` Jarkko Sakkinen
2018-11-19 14:59 ` Jarkko Sakkinen
2018-11-19 14:59 ` Jarkko Sakkinen
2018-11-19 15:29 ` Andy Lutomirski
2018-11-19 15:29 ` Andy Lutomirski
2018-11-19 16:02 ` Jarkko Sakkinen
2018-11-19 17:00 ` Andy Lutomirski
2018-11-19 17:00 ` Andy Lutomirski
2018-11-20 10:11 ` Jarkko Sakkinen
2018-11-20 15:19 ` Andy Lutomirski
2018-11-20 15:19 ` Andy Lutomirski
2018-11-20 22:55 ` Jarkko Sakkinen
2018-11-21 5:17 ` Jethro Beekman
2018-11-21 5:17 ` Jethro Beekman
2018-11-21 15:17 ` Jarkko Sakkinen
2018-11-21 15:17 ` Jarkko Sakkinen
2018-11-24 17:07 ` Jarkko Sakkinen
2018-11-24 17:07 ` Jarkko Sakkinen
2018-11-26 14:35 ` Sean Christopherson
2018-11-26 14:35 ` Sean Christopherson
2018-11-26 22:06 ` Jarkko Sakkinen
2018-11-26 22:06 ` Jarkko Sakkinen
2018-11-20 18:09 ` Sean Christopherson
2018-11-20 22:46 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly 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=20181108195420.GA14715@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dalias@libc.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fweimer@redhat.com \
--cc=jannh@google.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jethro@fortanix.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=nhorman@redhat.com \
--cc=npmccallum@redhat.com \
--cc=peterz@infradead.org \
--cc=serge.ayoun@intel.com \
--cc=shay.katz-zamir@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.