On Thu, 1 Nov 2018, Jarkko Sakkinen wrote:
On Wed, 31 Oct 2018, Sean Christopherson wrote:
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
1) Even though the vDSO function exists, userspace may still call
`ENCLU[EENTER]`
On Thu, 1 Nov 2018, Jarkko Sakkinen wrote:
On Wed, 31 Oct 2018, Sean Christopherson wrote:
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
1) Even though the vDSO function exists, userspace may still call
`ENCLU[EENTER]`
On Wed, 31 Oct 2018, Sean Christopherson wrote:
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
1) Even though the vDSO function exists, userspace may still call
`ENCLU[EENTER]` manually, so the fault handling as described in the
On Wed, 31 Oct 2018, Sean Christopherson wrote:
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
1) Even though the vDSO function exists, userspace may still call
`ENCLU[EENTER]` manually, so the fault handling as described in the
On 10/31/18 2:30 PM, Sean Christopherson wrote:
> On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
>> On 10/01/2018 02:42 PM, Jethro Beekman wrote:
>>>
>>> 1) Even though the vDSO function exists, userspace may still call
>>> `ENCLU[EENTER]` manually, so the fault handling as
On 10/31/18 2:30 PM, Sean Christopherson wrote:
> On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
>> On 10/01/2018 02:42 PM, Jethro Beekman wrote:
>>>
>>> 1) Even though the vDSO function exists, userspace may still call
>>> `ENCLU[EENTER]` manually, so the fault handling as
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
> On 10/01/2018 02:42 PM, Jethro Beekman wrote:
> >
> > 1) Even though the vDSO function exists, userspace may still call
> > `ENCLU[EENTER]` manually, so the fault handling as described in the
> > current patch should also be
On Mon, Oct 01, 2018 at 03:03:30PM -0700, Dave Hansen wrote:
> On 10/01/2018 02:42 PM, Jethro Beekman wrote:
> >
> > 1) Even though the vDSO function exists, userspace may still call
> > `ENCLU[EENTER]` manually, so the fault handling as described in the
> > current patch should also be
On Mon, Oct 01, 2018 at 09:42:48PM +, Jethro Beekman wrote:
> 1) Even though the vDSO function exists, userspace may still call
> `ENCLU[EENTER]` manually, so the fault handling as described in the current
> patch should also be maintained.
You mean the way it was is in v13 and not the way it
On Mon, Oct 01, 2018 at 09:42:48PM +, Jethro Beekman wrote:
> 1) Even though the vDSO function exists, userspace may still call
> `ENCLU[EENTER]` manually, so the fault handling as described in the current
> patch should also be maintained.
You mean the way it was is in v13 and not the way it
On Mon, Oct 01, 2018 at 07:29:03AM -0700, Sean Christopherson wrote:
> On Wed, 2018-09-26 at 14:15 -0700, Andy Lutomirski wrote:
> > runs an enclave an returns an error code, and rig up the #PF handler
> > to check if the error happened in the vDSO entry and fix it up rather
> > than sending a
On Mon, Oct 01, 2018 at 07:29:03AM -0700, Sean Christopherson wrote:
> On Wed, 2018-09-26 at 14:15 -0700, Andy Lutomirski wrote:
> > runs an enclave an returns an error code, and rig up the #PF handler
> > to check if the error happened in the vDSO entry and fix it up rather
> > than sending a
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
>
> 1) Even though the vDSO function exists, userspace may still call
> `ENCLU[EENTER]` manually, so the fault handling as described in the
> current patch should also be maintained.
Why?
On 10/01/2018 02:42 PM, Jethro Beekman wrote:
>
> 1) Even though the vDSO function exists, userspace may still call
> `ENCLU[EENTER]` manually, so the fault handling as described in the
> current patch should also be maintained.
Why?
On 2018-09-27 06:56, Jarkko Sakkinen wrote:
On Wed, Sep 26, 2018 at 02:45:17PM -0700, Dave Hansen wrote:
On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
Could we perhaps have a little vDSO entry (or syscall, I suppose) that
runs an enclave an returns an error code, and rig up the #PF handler
to
On 2018-09-27 06:56, Jarkko Sakkinen wrote:
On Wed, Sep 26, 2018 at 02:45:17PM -0700, Dave Hansen wrote:
On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
Could we perhaps have a little vDSO entry (or syscall, I suppose) that
runs an enclave an returns an error code, and rig up the #PF handler
to
On 10/01/2018 07:29 AM, Sean Christopherson wrote:
>> Could we perhaps have a little vDSO entry (or syscall, I suppose) that
>> runs an enclave an returns an error code, and rig up the #PF handler
>> to check if the error happened in the vDSO entry and fix it up rather
>> than sending a signal?
>
On 10/01/2018 07:29 AM, Sean Christopherson wrote:
>> Could we perhaps have a little vDSO entry (or syscall, I suppose) that
>> runs an enclave an returns an error code, and rig up the #PF handler
>> to check if the error happened in the vDSO entry and fix it up rather
>> than sending a signal?
>
On Wed, 2018-09-26 at 14:15 -0700, Andy Lutomirski wrote:
> On Wed, Sep 26, 2018 at 1:55 PM Dave Hansen wrote:
> >
> >
> > On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> > >
> > > On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> > > >
> > > > We also need to clarify how
On Wed, 2018-09-26 at 14:15 -0700, Andy Lutomirski wrote:
> On Wed, Sep 26, 2018 at 1:55 PM Dave Hansen wrote:
> >
> >
> > On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> > >
> > > On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> > > >
> > > > We also need to clarify how
On Thu, 2018-09-27 at 21:43 +0200, Eric W. Biederman wrote:
> Jarkko Sakkinen writes:
>
> > From: Sean Christopherson
> >
> > Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
> > error code. The PF_SGX bit is set if and only if the #PF is detected
> > by the Enclave Page
On Thu, 2018-09-27 at 21:43 +0200, Eric W. Biederman wrote:
> Jarkko Sakkinen writes:
>
> > From: Sean Christopherson
> >
> > Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
> > error code. The PF_SGX bit is set if and only if the #PF is detected
> > by the Enclave Page
Jarkko Sakkinen writes:
> From: Sean Christopherson
>
> Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
> error code. The PF_SGX bit is set if and only if the #PF is detected
> by the Enclave Page Cache Map (EPCM), which is consulted only after
> an access walks the kernel's
Jarkko Sakkinen writes:
> From: Sean Christopherson
>
> Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
> error code. The PF_SGX bit is set if and only if the #PF is detected
> by the Enclave Page Cache Map (EPCM), which is consulted only after
> an access walks the kernel's
On 09/27/2018 08:39 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 27, 2018 at 07:58:41AM -0700, Dave Hansen wrote:
>> On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
This flag is 1 if the exception is unrelated to paging and
resulted from violation of SGX-specific access-control
On 09/27/2018 08:39 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 27, 2018 at 07:58:41AM -0700, Dave Hansen wrote:
>> On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
This flag is 1 if the exception is unrelated to paging and
resulted from violation of SGX-specific access-control
On Thu, Sep 27, 2018 at 07:58:41AM -0700, Dave Hansen wrote:
> On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
> >>This flag is 1 if the exception is unrelated to paging and
> >>resulted from violation of SGX-specific access-control
> >>requirements. ... such a violation can occur only
On Thu, Sep 27, 2018 at 07:58:41AM -0700, Dave Hansen wrote:
> On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
> >>This flag is 1 if the exception is unrelated to paging and
> >>resulted from violation of SGX-specific access-control
> >>requirements. ... such a violation can occur only
On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
>> This flag is 1 if the exception is unrelated to paging and
>> resulted from violation of SGX-specific access-control
>> requirements. ... such a violation can occur only if there
>> is no ordinary page fault...
>>
>> This is
On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote:
>> This flag is 1 if the exception is unrelated to paging and
>> resulted from violation of SGX-specific access-control
>> requirements. ... such a violation can occur only if there
>> is no ordinary page fault...
>>
>> This is
> On Sep 27, 2018, at 7:21 AM, Jarkko Sakkinen
> wrote:
>
>> On Wed, Sep 26, 2018 at 03:37:45PM -0700, Andy Lutomirski wrote:
>> Yeah. Maybe like this: > > xorl %eax,%eax > eenter_insn:
>> ENCLU[whatever]
>> eenter_landing_pad:
>> ret
>>
>> And the kernel would use the existing vdso2c
> On Sep 27, 2018, at 7:21 AM, Jarkko Sakkinen
> wrote:
>
>> On Wed, Sep 26, 2018 at 03:37:45PM -0700, Andy Lutomirski wrote:
>> Yeah. Maybe like this: > > xorl %eax,%eax > eenter_insn:
>> ENCLU[whatever]
>> eenter_landing_pad:
>> ret
>>
>> And the kernel would use the existing vdso2c
On Wed, Sep 26, 2018 at 03:37:45PM -0700, Andy Lutomirski wrote:
> Yeah. Maybe like this: > > xorl %eax,%eax > eenter_insn:
> ENCLU[whatever]
> eenter_landing_pad:
> ret
>
> And the kernel would use the existing vdso2c vdso-symbol-finding
> mechanism to do the fixup.
>
> >
> > How would a
On Wed, Sep 26, 2018 at 03:37:45PM -0700, Andy Lutomirski wrote:
> Yeah. Maybe like this: > > xorl %eax,%eax > eenter_insn:
> ENCLU[whatever]
> eenter_landing_pad:
> ret
>
> And the kernel would use the existing vdso2c vdso-symbol-finding
> mechanism to do the fixup.
>
> >
> > How would a
On Wed, Sep 26, 2018 at 02:45:17PM -0700, Dave Hansen wrote:
> On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
> > Could we perhaps have a little vDSO entry (or syscall, I suppose) that
> > runs an enclave an returns an error code, and rig up the #PF handler
> > to check if the error happened in
On Wed, Sep 26, 2018 at 02:45:17PM -0700, Dave Hansen wrote:
> On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
> > Could we perhaps have a little vDSO entry (or syscall, I suppose) that
> > runs an enclave an returns an error code, and rig up the #PF handler
> > to check if the error happened in
On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
> >> e omniscient.
> >>
> >> How about this? With formatting changes since it's long-winded...
> >>
> >>/*
> >> * Access is blocked by the Enclave Page Cache Map (EPCM),
On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
> >> e omniscient.
> >>
> >> How about this? With formatting changes since it's long-winded...
> >>
> >>/*
> >> * Access is blocked by the Enclave Page Cache Map (EPCM),
On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote:
> Minor nit:
>
> On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
> wrote:
> >
> > From: Sean Christopherson
> >
>
> > by (c) as the kernel doesn't really have any other reasonable option,
> > e.g. we could kill the task or panic,
On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote:
> Minor nit:
>
> On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
> wrote:
> >
> > From: Sean Christopherson
> >
>
> > by (c) as the kernel doesn't really have any other reasonable option,
> > e.g. we could kill the task or panic,
On Wed, Sep 26, 2018 at 2:45 PM Dave Hansen wrote:
>
> On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
> > Could we perhaps have a little vDSO entry (or syscall, I suppose) that
> > runs an enclave an returns an error code, and rig up the #PF handler
> > to check if the error happened in the vDSO
On Wed, Sep 26, 2018 at 2:45 PM Dave Hansen wrote:
>
> On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
> > Could we perhaps have a little vDSO entry (or syscall, I suppose) that
> > runs an enclave an returns an error code, and rig up the #PF handler
> > to check if the error happened in the vDSO
On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
> Could we perhaps have a little vDSO entry (or syscall, I suppose) that
> runs an enclave an returns an error code, and rig up the #PF handler
> to check if the error happened in the vDSO entry and fix it up rather
> than sending a signal?
Yeah,
On 09/26/2018 02:15 PM, Andy Lutomirski wrote:
> Could we perhaps have a little vDSO entry (or syscall, I suppose) that
> runs an enclave an returns an error code, and rig up the #PF handler
> to check if the error happened in the vDSO entry and fix it up rather
> than sending a signal?
Yeah,
On Wed, Sep 26, 2018 at 1:55 PM Dave Hansen wrote:
>
> On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> > On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> >> We also need to clarify how this can happen. Is it through something
> >> than an app does, or is it solely when the
On Wed, Sep 26, 2018 at 1:55 PM Dave Hansen wrote:
>
> On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> > On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> >> We also need to clarify how this can happen. Is it through something
> >> than an app does, or is it solely when the
On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
>> We also need to clarify how this can happen. Is it through something
>> than an app does, or is it solely when the hardware does something under
>> the covers, like suspend/resume.
On 09/26/2018 01:44 PM, Sean Christopherson wrote:
> On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
>> We also need to clarify how this can happen. Is it through something
>> than an app does, or is it solely when the hardware does something under
>> the covers, like suspend/resume.
On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
> >> e omniscient.
> >>
> >> How about this? With formatting changes since it's long-winded...
> >>
> >>/*
> >> * Access is blocked by the Enclave Page Cache Map (EPCM),
On Wed, Sep 26, 2018 at 01:16:59PM -0700, Dave Hansen wrote:
> On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
> >> e omniscient.
> >>
> >> How about this? With formatting changes since it's long-winded...
> >>
> >>/*
> >> * Access is blocked by the Enclave Page Cache Map (EPCM),
On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
>> e omniscient.
>>
>> How about this? With formatting changes since it's long-winded...
>>
>>/*
>> * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
>> * access is allowed by the PTE but not the EPCM. This
On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
>> e omniscient.
>>
>> How about this? With formatting changes since it's long-winded...
>>
>>/*
>> * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
>> * access is allowed by the PTE but not the EPCM. This
> On Sep 26, 2018, at 10:35 AM, Sean Christopherson
> wrote:
>
>> On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote:
>> Minor nit:
>>
>> On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
>> wrote:
>>>
>>> From: Sean Christopherson
>>>
>>
>>> by (c) as the kernel doesn't
> On Sep 26, 2018, at 10:35 AM, Sean Christopherson
> wrote:
>
>> On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote:
>> Minor nit:
>>
>> On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
>> wrote:
>>>
>>> From: Sean Christopherson
>>>
>>
>>> by (c) as the kernel doesn't
On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote:
> Minor nit:
>
> On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
> wrote:
> >
> > From: Sean Christopherson
> >
>
> > by (c) as the kernel doesn't really have any other reasonable option,
> > e.g. we could kill the task or panic,
On Tue, Sep 25, 2018 at 03:53:48PM -0700, Andy Lutomirski wrote:
> Minor nit:
>
> On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
> wrote:
> >
> > From: Sean Christopherson
> >
>
> > by (c) as the kernel doesn't really have any other reasonable option,
> > e.g. we could kill the task or panic,
Minor nit:
On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
wrote:
>
> From: Sean Christopherson
>
> by (c) as the kernel doesn't really have any other reasonable option,
> e.g. we could kill the task or panic, but neither is warranted.
Not killing the task is quite nice, but...
> + /*
Minor nit:
On Tue, Sep 25, 2018 at 6:12 AM Jarkko Sakkinen
wrote:
>
> From: Sean Christopherson
>
> by (c) as the kernel doesn't really have any other reasonable option,
> e.g. we could kill the task or panic, but neither is warranted.
Not killing the task is quite nice, but...
> + /*
From: Sean Christopherson
Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
error code. The PF_SGX bit is set if and only if the #PF is detected
by the Enclave Page Cache Map (EPCM), which is consulted only after
an access walks the kernel's page tables, i.e.:
a. the access
From: Sean Christopherson
Signal SIGSEGV(SEGV_SGXERR) for all faults with PF_SGX set in the
error code. The PF_SGX bit is set if and only if the #PF is detected
by the Enclave Page Cache Map (EPCM), which is consulted only after
an access walks the kernel's page tables, i.e.:
a. the access
60 matches
Mail list logo
