On Thu, Jul 16, 2020 at 9:58 AM Jarkko Sakkinen
wrote:
>
> Add a selftest for SGX. It is a trivial test where a simple enclave
> copies one 64-bit word of memory between two memory locations.
>
> Cc: linux-kselft...@vger.kernel.org
> Signed-off-by: Jarkko Sakkinen
> ---
>
On Tue, Aug 18, 2020 at 12:44 PM Jarkko Sakkinen
wrote:
>
> On Tue, Aug 18, 2020 at 11:15:32AM -0400, Nathaniel McCallum wrote:
> > That seems like overkill to me. I'm just asking for one additional mov
> > instruction. :)
>
> I started to consider eBPF since the co
That seems like overkill to me. I'm just asking for one additional mov
instruction. :)
On Tue, Aug 18, 2020 at 11:06 AM Jarkko Sakkinen
wrote:
>
> On Tue, Aug 18, 2020 at 05:52:41PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Aug 10, 2020 at 03:23:17PM -0700, Sean Christopherson wrote:
> > > >
On Mon, Aug 10, 2020 at 7:09 PM Andy Lutomirski wrote:
>
> On Thu, Aug 6, 2020 at 7:55 AM Nathaniel McCallum
> wrote:
> >
> > In a past revision of this patch, I had requested a void *misc
> > parameter that could be passed through vdso_sgx_enter_enclave_t into
>
In a past revision of this patch, I had requested a void *misc
parameter that could be passed through vdso_sgx_enter_enclave_t into
sgx_enclave_exit_handler_t. This request encountered some push back
and I dropped the issue. However, I'd like to revisit it or something
similar.
One way to create
On Thu, May 14, 2020 at 5:17 AM Dr. Greg wrote:
>
> On Fri, May 08, 2020 at 12:56:35PM -0700, Sean Christopherson wrote:
>
> Good morning, I hope the week is proceeding well for everyone.
>
> > On Fri, May 08, 2020 at 02:02:26PM -0500, Dr. Greg wrote:
> > > On Thu, May 07, 2020 at 02:41:30AM
On Thu, May 7, 2020 at 1:03 AM Haitao Huang
wrote:
>
> On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson
> wrote:
>
> > On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote:
> >> Tested on Enarx. This requires a patch[0] for v29 support.
>
Tested on Enarx. This requires a patch[0] for v29 support.
Tested-by: Nathaniel McCallum
However, we did uncover a small usability issue. See below.
[0]:
https://github.com/enarx/enarx/pull/507/commits/80da2352aba46aa7bc6b4d1fccf20fe1bda58662
On Tue, Apr 21, 2020 at 5:53 PM Jarkko Sakkinen
I've been working on wrapping various SEV kernel APIs for userspace
consumption. There does not appear to be any privilege separation for
these commands: you can run them all or none of them. This is less
than ideal because it means that a compromise of the code which
launches VMs could make
I'm a little concerned that this immediately disables SEV_GET_ID.
IMHO, we should continue to support both for a period of time. One
justification for immediate disablement would be that if keeping it
around is likely to enabled incorrect or insecure userspace behavior
with a firmware change.
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, 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
&g
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
&g
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 t
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 t
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 followin
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 followin
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
&
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
&
and freedom.
[0]: details here -
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19
On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote:
>
> On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote:
> > On Wed, Jun 20, 2018 at
and freedom.
[0]: details here -
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/README#n19
On Thu, Jun 21, 2018 at 11:29 AM Neil Horman wrote:
>
> On Thu, Jun 21, 2018 at 08:32:25AM -0400, Nathaniel McCallum wrote:
> > On Wed, Jun 20, 2018 at
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:
> >
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:
> >
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
I apologize if this is the wrong mailing list for this query. I wasn't
sure where else to post it.
In user space, I have a process hierarchy. There is a root process
which spawns a child which in turn may spawn more children. Hence, I
have a standard hierarchy with a root process, zero or more
I apologize if this is the wrong mailing list for this query. I wasn't
sure where else to post it.
In user space, I have a process hierarchy. There is a root process
which spawns a child which in turn may spawn more children. Hence, I
have a standard hierarchy with a root process, zero or more
30 matches
Mail list logo
