On Tue, 2018-06-26 at 11:01 -0400, Nathaniel McCallum wrote:
> On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen
> wrote:
> >
> > On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote:
> > > I'm personally rather strongly in favor of the vastly simpler model in
> > > which we first merge SGX
On Tue, 2018-06-26 at 11:01 -0400, Nathaniel McCallum wrote:
> On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen
> wrote:
> >
> > On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote:
> > > I'm personally rather strongly in favor of the vastly simpler model in
> > > which we first merge SGX
On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen
wrote:
>
> On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote:
> > I'm personally rather strongly in favor of the vastly simpler model in
> > which we first merge SGX without LE support at all. Instead we use
> > the approach where we just
On Tue, Jun 26, 2018 at 4:44 AM Jarkko Sakkinen
wrote:
>
> On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote:
> > I'm personally rather strongly in favor of the vastly simpler model in
> > which we first merge SGX without LE support at all. Instead we use
> > the approach where we just
On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote:
> I'm personally rather strongly in favor of the vastly simpler model in
> which we first merge SGX without LE support at all. Instead we use
> the approach where we just twiddle the MSRs to launch normal enclaves
> without an init token
On Mon, 2018-06-25 at 08:45 -0700, Andy Lutomirski wrote:
> I'm personally rather strongly in favor of the vastly simpler model in
> which we first merge SGX without LE support at all. Instead we use
> the approach where we just twiddle the MSRs to launch normal enclaves
> without an init token
On Mon, Jun 25, 2018 at 2:06 PM Nathaniel McCallum
wrote:
>
> On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote:
> >
> > On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum
> > wrote:
> > >
> > > If this is acceptable for everyone, my hope is the following:
> > >
> > > 1. Intel would split
On Mon, Jun 25, 2018 at 2:06 PM Nathaniel McCallum
wrote:
>
> On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote:
> >
> > On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum
> > wrote:
> > >
> > > If this is acceptable for everyone, my hope is the following:
> > >
> > > 1. Intel would split
On Mon, Jun 25, 2018 at 05:00:05PM -0400, Nathaniel McCallum wrote:
> On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson
> wrote:
> >
> > On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote:
> > > If this is acceptable for everyone, my hope is the following:
> > >
> > > 1. Intel
On Mon, Jun 25, 2018 at 05:00:05PM -0400, Nathaniel McCallum wrote:
> On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson
> wrote:
> >
> > On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote:
> > > If this is acceptable for everyone, my hope is the following:
> > >
> > > 1. Intel
On Mon, Jun 25, 2018 at 11:45 AM Andy Lutomirski wrote:
>
> On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen
> wrote:
> >
> > On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> > > This implies that it should be possible to create MSR activation (and
> > > an embedded launch enclave?)
On Mon, Jun 25, 2018 at 11:45 AM Andy Lutomirski wrote:
>
> On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen
> wrote:
> >
> > On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> > > This implies that it should be possible to create MSR activation (and
> > > an embedded launch enclave?)
On Mon, Jun 25, 2018 at 5:28 AM Jarkko Sakkinen
wrote:
>
> On Wed, 2018-06-20 at 12:28 -0400, Nathaniel McCallum wrote:
> > As I understand it, the current policy models under discussion look like
> > this:
> >
> > 1. SGX w/o FLC (not being merged) looks like this:
> > Intel CPU => (Intel
On Mon, Jun 25, 2018 at 5:28 AM Jarkko Sakkinen
wrote:
>
> On Wed, 2018-06-20 at 12:28 -0400, Nathaniel McCallum wrote:
> > As I understand it, the current policy models under discussion look like
> > this:
> >
> > 1. SGX w/o FLC (not being merged) looks like this:
> > Intel CPU => (Intel
On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote:
>
> On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum
> wrote:
> >
> > If this is acceptable for everyone, my hope is the following:
> >
> > 1. Intel would split the existing code into one of the following
> > schemas (I don't care which):
On Thu, Jun 21, 2018 at 6:49 PM Andy Lutomirski wrote:
>
> On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum
> wrote:
> >
> > If this is acceptable for everyone, my hope is the following:
> >
> > 1. Intel would split the existing code into one of the following
> > schemas (I don't care which):
On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson
wrote:
>
> On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote:
> > If this is acceptable for everyone, my hope is the following:
> >
> > 1. Intel would split the existing code into one of the following
> > schemas (I don't care
On Thu, Jun 21, 2018 at 5:21 PM Sean Christopherson
wrote:
>
> On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote:
> > If this is acceptable for everyone, my hope is the following:
> >
> > 1. Intel would split the existing code into one of the following
> > schemas (I don't care
On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen
wrote:
>
> On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> > This implies that it should be possible to create MSR activation (and
> > an embedded launch enclave?) entirely as a UEFI module. The kernel
> > would still get to manage
On Mon, Jun 25, 2018 at 2:41 AM Jarkko Sakkinen
wrote:
>
> On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> > This implies that it should be possible to create MSR activation (and
> > an embedded launch enclave?) entirely as a UEFI module. The kernel
> > would still get to manage
On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> This implies that it should be possible to create MSR activation (and
> an embedded launch enclave?) entirely as a UEFI module. The kernel
> would still get to manage who has access to /dev/sgx and other
> important non-cryptographic
On Thu, 2018-06-21 at 08:32 -0400, Nathaniel McCallum wrote:
> This implies that it should be possible to create MSR activation (and
> an embedded launch enclave?) entirely as a UEFI module. The kernel
> would still get to manage who has access to /dev/sgx and other
> important non-cryptographic
On Wed, 2018-06-20 at 12:28 -0400, Nathaniel McCallum wrote:
> As I understand it, the current policy models under discussion look like this:
>
> 1. SGX w/o FLC (not being merged) looks like this:
> Intel CPU => (Intel signed) launch enclave => enclaves
>
> 2. SGX w/ FLC, looks like this:
>
On Wed, 2018-06-20 at 12:28 -0400, Nathaniel McCallum wrote:
> As I understand it, the current policy models under discussion look like this:
>
> 1. SGX w/o FLC (not being merged) looks like this:
> Intel CPU => (Intel signed) launch enclave => enclaves
>
> 2. SGX w/ FLC, looks like this:
>
On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum
wrote:
>
> If this is acceptable for everyone, my hope is the following:
>
> 1. Intel would split the existing code into one of the following
> schemas (I don't care which):
> A. three parts: UEFI module, FLC-only kernel driver and user-space
On Thu, Jun 21, 2018 at 12:11 PM Nathaniel McCallum
wrote:
>
> If this is acceptable for everyone, my hope is the following:
>
> 1. Intel would split the existing code into one of the following
> schemas (I don't care which):
> A. three parts: UEFI module, FLC-only kernel driver and user-space
On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote:
> If this is acceptable for everyone, my hope is the following:
>
> 1. Intel would split the existing code into one of the following
> schemas (I don't care which):
> A. three parts: UEFI module, FLC-only kernel driver and
On Thu, Jun 21, 2018 at 03:11:18PM -0400, Nathaniel McCallum wrote:
> If this is acceptable for everyone, my hope is the following:
>
> 1. Intel would split the existing code into one of the following
> schemas (I don't care which):
> A. three parts: UEFI module, FLC-only kernel driver and
If this is acceptable for everyone, my hope is the following:
1. Intel would split the existing code into one of the following
schemas (I don't care which):
A. three parts: UEFI module, FLC-only kernel driver and user-space
launch enclave
B. two parts: UEFI module (including launch enclave)
If this is acceptable for everyone, my hope is the following:
1. Intel would split the existing code into one of the following
schemas (I don't care which):
A. three parts: UEFI module, FLC-only kernel driver and user-space
launch enclave
B. two parts: UEFI module (including launch enclave)
On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote:
> On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson
> wrote:
> >
> > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote:
> > > On 2018-06-20 11:16, Jethro Beekman wrote:
> > > > > This last bit is also repeated in
On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote:
> On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson
> wrote:
> >
> > On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote:
> > > On 2018-06-20 11:16, Jethro Beekman wrote:
> > > > > This last bit is also repeated in
On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson
wrote:
>
> On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote:
> > On 2018-06-20 11:16, Jethro Beekman wrote:
> > > > This last bit is also repeated in different words in Table 35-2 and
> > > > Section 42.2.2. The MSRs are *not
On Wed, Jun 20, 2018 at 5:02 PM Sean Christopherson
wrote:
>
> On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote:
> > On 2018-06-20 11:16, Jethro Beekman wrote:
> > > > This last bit is also repeated in different words in Table 35-2 and
> > > > Section 42.2.2. The MSRs are *not
On Wed, Jun 20, 2018 at 2:16 PM Jethro Beekman wrote:
>
> On 2018-06-20 09:28, Nathaniel McCallum wrote:
> > As I understand it, the current policy models under discussion look like
> > this:
> >
> > 1. SGX w/o FLC (not being merged) looks like this:
> >Intel CPU => (Intel signed) launch
On Wed, Jun 20, 2018 at 2:16 PM Jethro Beekman wrote:
>
> On 2018-06-20 09:28, Nathaniel McCallum wrote:
> > As I understand it, the current policy models under discussion look like
> > this:
> >
> > 1. SGX w/o FLC (not being merged) looks like this:
> >Intel CPU => (Intel signed) launch
On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote:
> On 2018-06-20 11:16, Jethro Beekman wrote:
> > > This last bit is also repeated in different words in Table 35-2 and
> > > Section 42.2.2. The MSRs are *not writable* before the write-lock bit
> > > itself is locked. Meaning the
On Wed, Jun 20, 2018 at 11:39:00AM -0700, Jethro Beekman wrote:
> On 2018-06-20 11:16, Jethro Beekman wrote:
> > > This last bit is also repeated in different words in Table 35-2 and
> > > Section 42.2.2. The MSRs are *not writable* before the write-lock bit
> > > itself is locked. Meaning the
On 2018-06-20 11:16, Jethro Beekman wrote:
> This last bit is also repeated in different words in Table 35-2 and
> Section 42.2.2. The MSRs are *not writable* before the write-lock bit
> itself is locked. Meaning the MSRs are either locked with Intel's key
> hash, or not locked at all.
On 2018-06-20 11:16, Jethro Beekman wrote:
> This last bit is also repeated in different words in Table 35-2 and
> Section 42.2.2. The MSRs are *not writable* before the write-lock bit
> itself is locked. Meaning the MSRs are either locked with Intel's key
> hash, or not locked at all.
On 2018-06-20 09:28, Nathaniel McCallum wrote:
As I understand it, the current policy models under discussion look like this:
1. SGX w/o FLC (not being merged) looks like this:
Intel CPU => (Intel signed) launch enclave => enclaves
I think you mean:
Intel CPU => kernel => (Intel
On 2018-06-20 09:28, Nathaniel McCallum wrote:
As I understand it, the current policy models under discussion look like this:
1. SGX w/o FLC (not being merged) looks like this:
Intel CPU => (Intel signed) launch enclave => enclaves
I think you mean:
Intel CPU => kernel => (Intel
As I understand it, the current policy models under discussion look like this:
1. SGX w/o FLC (not being merged) looks like this:
Intel CPU => (Intel signed) launch enclave => enclaves
2. SGX w/ FLC, looks like this:
Intel CPU => kernel => launch enclave => enclaves
3. Andy is proposing
As I understand it, the current policy models under discussion look like this:
1. SGX w/o FLC (not being merged) looks like this:
Intel CPU => (Intel signed) launch enclave => enclaves
2. SGX w/ FLC, looks like this:
Intel CPU => kernel => launch enclave => enclaves
3. Andy is proposing
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> >
> > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > wrote:
> >>
> >> The Launch Enclave (LE) generates cryptographic launch tokens for user
> >> enclaves. A launch
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> >
> > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > wrote:
> >>
> >> The Launch Enclave (LE) generates cryptographic launch tokens for user
> >> enclaves. A launch
On Fri, Jun 08, 2018 at 11:50:14AM -0700, Andy Lutomirski wrote:
> On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> wrote:
> >
> > The Launch Enclave (LE) generates cryptographic launch tokens for user
> > enclaves. A launch token is used by EINIT to check whether the enclave
> > is authorized
On Fri, Jun 08, 2018 at 11:50:14AM -0700, Andy Lutomirski wrote:
> On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> wrote:
> >
> > The Launch Enclave (LE) generates cryptographic launch tokens for user
> > enclaves. A launch token is used by EINIT to check whether the enclave
> > is authorized
On Mon, Jun 18, 2018 at 02:58:59PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote:
> >
> > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote:
> > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
> > > >
> > > > On Sun, Jun 10, 2018 at
On Mon, Jun 18, 2018 at 02:58:59PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote:
> >
> > On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote:
> > > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
> > > >
> > > > On Sun, Jun 10, 2018 at
On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote:
>
> On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote:
> > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
> > >
> > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > > > On Jun 9, 2018, at 10:39 PM, Andy
On Tue, Jun 12, 2018 at 10:45 AM Neil Horman wrote:
>
> On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote:
> > On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
> > >
> > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > > > On Jun 9, 2018, at 10:39 PM, Andy
On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
> >
> > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> > > >
> > > > On Fri, Jun 8, 2018 at 10:32
On Mon, Jun 11, 2018 at 09:55:29PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
> >
> > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> > > >
> > > > On Fri, Jun 8, 2018 at 10:32
On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
>
> On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> > >
> > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > > wrote:
> > >>
> > >> The Launch Enclave (LE)
On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote:
>
> On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> > >
> > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > > wrote:
> > >>
> > >> The Launch Enclave (LE)
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> >
> > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > wrote:
> >>
> >> The Launch Enclave (LE) generates cryptographic launch tokens for user
> >> enclaves. A launch
On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote:
> > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
> >
> > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> > wrote:
> >>
> >> The Launch Enclave (LE) generates cryptographic launch tokens for user
> >> enclaves. A launch
> On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
>
> On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> wrote:
>>
>> The Launch Enclave (LE) generates cryptographic launch tokens for user
>> enclaves. A launch token is used by EINIT to check whether the enclave
>> is authorized to launch or
> On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote:
>
> On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
> wrote:
>>
>> The Launch Enclave (LE) generates cryptographic launch tokens for user
>> enclaves. A launch token is used by EINIT to check whether the enclave
>> is authorized to launch or
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
wrote:
>
> The Launch Enclave (LE) generates cryptographic launch tokens for user
> enclaves. A launch token is used by EINIT to check whether the enclave
> is authorized to launch or not. By having its own launch enclave, Linux
> has full control
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
wrote:
>
> The Launch Enclave (LE) generates cryptographic launch tokens for user
> enclaves. A launch token is used by EINIT to check whether the enclave
> is authorized to launch or not. By having its own launch enclave, Linux
> has full control
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
wrote:
>
> The Launch Enclave (LE) generates cryptographic launch tokens for user
> enclaves. A launch token is used by EINIT to check whether the enclave
> is authorized to launch or not. By having its own launch enclave, Linux
> has full control
On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen
wrote:
>
> The Launch Enclave (LE) generates cryptographic launch tokens for user
> enclaves. A launch token is used by EINIT to check whether the enclave
> is authorized to launch or not. By having its own launch enclave, Linux
> has full control
64 matches
Mail list logo
