On Tue, Dec 19, 2017 at 11:24:55PM +, Christopherson, Sean J wrote:
> Exposing the token generated by the in-kernel LE doesn't affect the
> kernel's power in the slightest, e.g. the kernel doesn't need a LE
> to refuse to run an enclave and a privileged user can always load
> an out-of-tree
On Tue, Dec 19, 2017 at 11:24:55PM +, Christopherson, Sean J wrote:
> Exposing the token generated by the in-kernel LE doesn't affect the
> kernel's power in the slightest, e.g. the kernel doesn't need a LE
> to refuse to run an enclave and a privileged user can always load
> an out-of-tree
On Tuesday, December 19, 2017 Jarkko Sakkinen wrote:
> On Tue, 2017-12-19 at 18:52 +, Christopherson, Sean J wrote:
> > > We can cache tokens in future in the kernel space, can't we?
> >
> > Yes, but why? Deferring to userspace is less complex and likely
> > more performant.
>
> That's
On Tuesday, December 19, 2017 Jarkko Sakkinen wrote:
> On Tue, 2017-12-19 at 18:52 +, Christopherson, Sean J wrote:
> > > We can cache tokens in future in the kernel space, can't we?
> >
> > Yes, but why? Deferring to userspace is less complex and likely
> > more performant.
>
> That's
On Tue, 2017-12-19 at 18:52 +, Christopherson, Sean J wrote:
> > We can cache tokens in future in the kernel space, can't we?
>
> Yes, but why? Deferring to userspace is less complex and likely
> more performant.
That's quite strong argument especially if you are making that for
systems
On Tue, 2017-12-19 at 18:52 +, Christopherson, Sean J wrote:
> > We can cache tokens in future in the kernel space, can't we?
>
> Yes, but why? Deferring to userspace is less complex and likely
> more performant.
That's quite strong argument especially if you are making that for
systems
On Friday, 2017-12-15, Jarkko Sakkinen wrote:
> > Resurrecting this thread now that I have a system with launch control
> > and have been able to measure the performance impact...
> >
> > Regenerating the EINIT token every time adds somewhere in the vicinity
> > of ~5% overhead to creating an
On Friday, 2017-12-15, Jarkko Sakkinen wrote:
> > Resurrecting this thread now that I have a system with launch control
> > and have been able to measure the performance impact...
> >
> > Regenerating the EINIT token every time adds somewhere in the vicinity
> > of ~5% overhead to creating an
On Wed, Dec 13, 2017 at 11:18:29PM +, Christopherson, Sean J wrote:
> Resurrecting this thread now that I have a system with launch control
> and have been able to measure the performance impact...
>
> Regenerating the EINIT token every time adds somewhere in the vicinity
> of ~5% overhead to
On Wed, Dec 13, 2017 at 11:18:29PM +, Christopherson, Sean J wrote:
> Resurrecting this thread now that I have a system with launch control
> and have been able to measure the performance impact...
>
> Regenerating the EINIT token every time adds somewhere in the vicinity
> of ~5% overhead to
On Wed, Nov 15, 2017 at 10:20:27AM -0800, Sean Christopherson wrote:
> On Tue, 2017-11-14 at 22:28 +0200, Jarkko Sakkinen wrote:
> > On Tue, Nov 14, 2017 at 09:55:06AM -0800, Sean Christopherson wrote:
> > >
> > > What do you mean by bottlenecks? Assuming you're referring to performance
> > >
On Wed, Nov 15, 2017 at 10:20:27AM -0800, Sean Christopherson wrote:
> On Tue, 2017-11-14 at 22:28 +0200, Jarkko Sakkinen wrote:
> > On Tue, Nov 14, 2017 at 09:55:06AM -0800, Sean Christopherson wrote:
> > >
> > > What do you mean by bottlenecks? Assuming you're referring to performance
> > >
On Tue, Nov 14, 2017 at 10:12:25PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 10:41:50AM +1100, James Morris wrote:
> > > + if (IS_ERR(secs_epc)) {
> > > + ret = PTR_ERR(secs_epc);
> > > + goto out;
> > > + }
> >
> > > +out:
> > > + if (encl)
> > > +
On Tue, Nov 14, 2017 at 10:12:25PM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 10:41:50AM +1100, James Morris wrote:
> > > + if (IS_ERR(secs_epc)) {
> > > + ret = PTR_ERR(secs_epc);
> > > + goto out;
> > > + }
> >
> > > +out:
> > > + if (encl)
> > > +
On Tue, 2017-11-14 at 22:28 +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 09:55:06AM -0800, Sean Christopherson wrote:
> >
> > What do you mean by bottlenecks? Assuming you're referring to performance
> > bottlenecks, this statement is flat out false. Moving the launch enclave
> >
On Tue, 2017-11-14 at 22:28 +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 14, 2017 at 09:55:06AM -0800, Sean Christopherson wrote:
> >
> > What do you mean by bottlenecks? Assuming you're referring to performance
> > bottlenecks, this statement is flat out false. Moving the launch enclave
> >
On Tue, Nov 14, 2017 at 09:55:06AM -0800, Sean Christopherson wrote:
> What do you mean by bottlenecks? Assuming you're referring to performance
> bottlenecks, this statement is flat out false. Moving the launch enclave into
> the kernel introduces performance bottlenecks, e.g. as implemented, a
On Tue, Nov 14, 2017 at 09:55:06AM -0800, Sean Christopherson wrote:
> What do you mean by bottlenecks? Assuming you're referring to performance
> bottlenecks, this statement is flat out false. Moving the launch enclave into
> the kernel introduces performance bottlenecks, e.g. as implemented, a
On Tue, Nov 14, 2017 at 10:41:50AM +1100, James Morris wrote:
> On Mon, 13 Nov 2017, Jarkko Sakkinen wrote:
>
> > +
> > + secs_epc = sgx_alloc_page(0);
>
> Use SGX_ALLOC_ATOMIC instead of 0 ?
It is used in the #PF handler where it is not safe to swap pages in the
call context. I.e. you cannot
On Tue, Nov 14, 2017 at 10:41:50AM +1100, James Morris wrote:
> On Mon, 13 Nov 2017, Jarkko Sakkinen wrote:
>
> > +
> > + secs_epc = sgx_alloc_page(0);
>
> Use SGX_ALLOC_ATOMIC instead of 0 ?
It is used in the #PF handler where it is not safe to swap pages in the
call context. I.e. you cannot
On Mon, 2017-11-13 at 21:45 +0200, Jarkko Sakkinen wrote:
> Intel SGX is a set of CPU instructions that can be used by applications
> to set aside private regions of code and data. The code outside the
> enclave is disallowed to access the memory inside the enclave by the CPU
> access control.
>
On Mon, 2017-11-13 at 21:45 +0200, Jarkko Sakkinen wrote:
> Intel SGX is a set of CPU instructions that can be used by applications
> to set aside private regions of code and data. The code outside the
> enclave is disallowed to access the memory inside the enclave by the CPU
> access control.
>
On Mon, 13 Nov 2017, Jarkko Sakkinen wrote:
> +
> + secs_epc = sgx_alloc_page(0);
Use SGX_ALLOC_ATOMIC instead of 0 ?
> + if (IS_ERR(secs_epc)) {
> + ret = PTR_ERR(secs_epc);
> + goto out;
> + }
> +out:
> + if (encl)
> + kref_put(>refcount,
On Mon, 13 Nov 2017, Jarkko Sakkinen wrote:
> +
> + secs_epc = sgx_alloc_page(0);
Use SGX_ALLOC_ATOMIC instead of 0 ?
> + if (IS_ERR(secs_epc)) {
> + ret = PTR_ERR(secs_epc);
> + goto out;
> + }
> +out:
> + if (encl)
> + kref_put(>refcount,
Intel SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the
enclave is disallowed to access the memory inside the enclave by the CPU
access control.
SGX driver provides a ioctl API for loading and initializing
Intel SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the
enclave is disallowed to access the memory inside the enclave by the CPU
access control.
SGX driver provides a ioctl API for loading and initializing
26 matches
Mail list logo
