Fork and Execv
76 views
Skip to first unread message
Taylor A. Hardin
Sep 7, 2021, 3:28:10 PM9/7/21
to sup...@graphene-project.io
Hello,
I had a question regarding the use of the fork and execv system calls with graphene-sgx. That is, if I have a program running under graphene-sgx (e.g.,
graphene-sgx ./my_program) which uses either of these system calls, will the new process execute within the same enclave that
my_program is in or a separate enclave? Or will it not be executed in an enclave at all? If the second process is being placed into its own enclave, are the command line arguments passed with execv secure?
Thanks,
Taylor
Borys
Sep 8, 2021, 7:24:45 AM9/8/21
to Taylor A. Hardin, sup...@graphene-project.io
Hello,
In the fork case the new process will run in a separate enclave that will be locally attested. All secrets/data are sent via TLS encrypted channel after the attestation.
In case of execve, the new program is run in the same enclave, so yes, execve arguments are secure.
Borys
In the fork case the new process will run in a separate enclave that will be locally attested. All secrets/data are sent via TLS encrypted channel after the attestation.
In case of execve, the new program is run in the same enclave, so yes, execve arguments are secure.
Borys
Taylor A. Hardin
Sep 8, 2021, 9:34:59 AM9/8/21
to Borys, sup...@graphene-project.io
Hi Borys,
Thank you very much for the response. Would the call
system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to
dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:- Have program A write the secrets to
dev/attestation/user_report_data - Have program A call fork
- Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
- Have the child process call execv and pass the secret to program B as a command line argument
Taylor
From: Borys <bor...@invisiblethingslab.com>
Sent: Wednesday, September 8, 2021 7:24 AM
To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; sup...@graphene-project.io <sup...@graphene-project.io>
Subject: Re: [graphene-support] Fork and Execv
Sent: Wednesday, September 8, 2021 7:24 AM
To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; sup...@graphene-project.io <sup...@graphene-project.io>
Subject: Re: [graphene-support] Fork and Execv
Borys
Sep 8, 2021, 9:48:13 AM9/8/21
to Taylor A. Hardin, sup...@graphene-project.io
Graphene emulates Linux on a syscall level (basically hijacks every syscall instruction, be it via modified libc or directly emulating it). system() is a function from C standard library and as such does not differ from any other code run, from the Graphene's point of view.
Such emulation allows us to transparently handle everything without cooperation from the application (hence you can run unmodified ELF binaries). This means you don't need to worry about attestation (or anything else) when doing fork or execve syscalls (directly or by using wrapper functions, like system()).
"/dev/attestation" subsystem needs to be used when doing *remote attestation*, it's not used for local attestation (and even if it was, you wouldn't have to worry about it, since it's done automatically by Graphene).
For local tests you can ignore remote attestation, it's needed when you want to safely run the application on another, untrusted machine. You can check our RA-TLS example for more information.
Borys
On 9/8/21 3:34 PM, Taylor A. Hardin wrote:
> Hi Borys,
>
> Thank you very much for the response. Would the call system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
>
> It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:
>
> 1. Have program A write the secrets to dev/attestation/user_report_data
> 2. Have program A call fork
> 3. Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
> 4. Have the child process call execv and pass the secret to program B as a command line argument
Such emulation allows us to transparently handle everything without cooperation from the application (hence you can run unmodified ELF binaries). This means you don't need to worry about attestation (or anything else) when doing fork or execve syscalls (directly or by using wrapper functions, like system()).
"/dev/attestation" subsystem needs to be used when doing *remote attestation*, it's not used for local attestation (and even if it was, you wouldn't have to worry about it, since it's done automatically by Graphene).
For local tests you can ignore remote attestation, it's needed when you want to safely run the application on another, untrusted machine. You can check our RA-TLS example for more information.
Borys
On 9/8/21 3:34 PM, Taylor A. Hardin wrote:
> Hi Borys,
>
> Thank you very much for the response. Would the call system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
>
> It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:
>
> 2. Have program A call fork
> 3. Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
> 4. Have the child process call execv and pass the secret to program B as a command line argument
Taylor A. Hardin
Sep 8, 2021, 10:42:55 AM9/8/21
to Borys, sup...@graphene-project.io
Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression
test for attestation, the local attestation function writes custom data to
/dev/attestation/user_report_data which appears to be included in the report and later verified by
verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
In the
ra-tls source code for the ra-tls-secret-prov example, however, it looks like secrets are provisioned via an mbedtls session that gets configured after remote attestation. Does that mean I should also provision secrets via
TLS for local attestations as well (i.e., for two enclaves running on the same machine)?
I think I already have everything I need now that I know
fork() creates a new enclave and
execv() replaces the process in the current enclave; I was just curious as to what purposes /dev/attestation/user_report_data and
/dev/target_info serve though.
Taylor
From: Borys <bor...@invisiblethingslab.com>
Sent: Wednesday, September 8, 2021 9:48 AM
Sent: Wednesday, September 8, 2021 9:48 AM
Borys
Sep 8, 2021, 10:54:05 AM9/8/21
to Taylor A. Hardin, sup...@graphene-project.io
"LibOS/shim/test/regression/attestation.c" is just to test Graphene interfaces, it's not an example to be followed.
As I said before, you don't have to do the local attestation by yourself, it's handled by the Graphene transparently.
If I remember correctly, in RA-TLS example the TLS session is tied to remote attestation (so that you can be sure that the TLS is terminated inside the enclave). That example uses "/dev/attestation/" interfaces to bind the TLS sesion to SGX report/quote. After you have a TLS connection established and verified and attested the other end, you can send any secrets (e.g. protected files key).
Borys
On 9/8/21 4:42 PM, Taylor A. Hardin wrote:
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://github.com/gramineproject/graphene/blob/master/LibOS/shim/test/regression/attestation.c>, the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
As I said before, you don't have to do the local attestation by yourself, it's handled by the Graphene transparently.
If I remember correctly, in RA-TLS example the TLS session is tied to remote attestation (so that you can be sure that the TLS is terminated inside the enclave). That example uses "/dev/attestation/" interfaces to bind the TLS sesion to SGX report/quote. After you have a TLS connection established and verified and attested the other end, you can send any secrets (e.g. protected files key).
Borys
On 9/8/21 4:42 PM, Taylor A. Hardin wrote:
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://github.com/gramineproject/graphene/blob/master/LibOS/shim/test/regression/attestation.c>, the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
Kuvaiskii, Dmitrii
Sep 8, 2021, 10:55:20 AM9/8/21
to Taylor A. Hardin, Borys, sup...@graphene-project.io
Dear Taylor,
There are two separate ways of communication between Graphene processes (SGX enclaves):
- Graphene enclaves that are “relatives”: these are parents, children, grandchildren, etc, created via fork/exec family of system calls. These “relatives” Graphene enclaves automatically
and transparently SGX-attest each other and automatically and transparently encrypt all traffic between them (including all traffic on signals/pipes/UNIX domain sockets that connect these “relatives”). No explicit SGX local/remote attestation is needed for
these “relatives” (i.e., no need for explicitly accessing `/dev/attestation/` files).
- Graphene enclaves that are not “relatives”: these are just two Graphene instances started completely separately (e.g., you start `graphene-sgx app1` in one bash terminal and `graphene-sgx app2` in another bash terminal). In this case, even if these Graphene enclaves run on the same machine, there is no automatic attestation/connection between these enclaves (well, obviously, they were started separately and don’t even know about each other). In this case, if you want to connect these enclaves, you need to explicitly create a socket between them (just like you would do for normal applications). And in this case, you *need* to add SGX local/remote attestation and also *explicit encryption* (e.g., wrap your socket connections in TLS sessions). And for this case, you need to *explicitly do SGX attestation* via `/dev/attestation/` files.
And of course, if you need SGX remote attestation, you need to use one of the following:
- Low-level `/dev/attestation` primitives; this is cumbersome but very powerful, you control everything.
- Mid-level RA-TLS library; this is easier but still requires some additional code and building steps.
- High-level Secret Provisioning library; this one is the easiest but provides only some limited functionality.
--
Dmitrii
--
You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
graphene-suppo...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
Taylor A. Hardin
Sep 8, 2021, 10:56:02 AM9/8/21
to Borys, sup...@graphene-project.io
Ah, ok. Thank you again for all your help!
Taylor
From: Borys <bor...@invisiblethingslab.com>
Sent: Wednesday, September 8, 2021 10:53 AM
Sent: Wednesday, September 8, 2021 10:53 AM
To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; sup...@graphene-project.io <sup...@graphene-project.io>
Subject: Re: [graphene-support] Fork and Execv
"LibOS/shim/test/regression/attestation.c" is just to test Graphene interfaces, it's not an example to be followed.
As I said before, you don't have to do the local attestation by yourself, it's handled by the Graphene transparently.
If I remember correctly, in RA-TLS example the TLS session is tied to remote attestation (so that you can be sure that the TLS is terminated inside the enclave). That example uses "/dev/attestation/" interfaces to bind the TLS sesion to SGX report/quote. After you have a TLS connection established and verified and attested the other end, you can send any secrets (e.g. protected files key).
Borys
On 9/8/21 4:42 PM, Taylor A. Hardin wrote:
As I said before, you don't have to do the local attestation by yourself, it's handled by the Graphene transparently.
If I remember correctly, in RA-TLS example the TLS session is tied to remote attestation (so that you can be sure that the TLS is terminated inside the enclave). That example uses "/dev/attestation/" interfaces to bind the TLS sesion to SGX report/quote. After you have a TLS connection established and verified and attested the other end, you can send any secrets (e.g. protected files key).
Borys
On 9/8/21 4:42 PM, Taylor A. Hardin wrote:
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgramineproject%2Fgraphene%2Fblob%2Fmaster%2FLibOS%2Fshim%2Ftest%2Fregression%2Fattestation.c&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7C8c76803777c243fd2d3708d972d87fdc%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667096449831799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m6PCxiDq9X3UVl67KYktsWvxpvk1q200cMbvtLht6Rw%3D&reserved=0>,
the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
Borys
Sep 8, 2021, 11:05:16 AM9/8/21
to Kuvaiskii, Dmitrii, Taylor A. Hardin, sup...@graphene-project.io
Please don't try connecting "unrelated" Graphene enclaves running on one machine, it's a footgun. You can easily spawn multiple processes in one Graphene "instance"/enclave using a simple wrapper (in bash,python,C, whatever).
Borys
On 9/8/21 4:54 PM, Kuvaiskii, Dmitrii wrote:
> Dear Taylor,
>
> There are two separate ways of communication between Graphene processes (SGX enclaves):
>
>
> * Graphene enclaves that are “relatives”: these are parents, children, grandchildren, etc, created via fork/exec family of system calls. These “relatives” Graphene enclaves automatically and transparently SGX-attest each other and automatically and transparently encrypt all traffic between them (including all traffic on signals/pipes/UNIX domain sockets that connect these “relatives”). No explicit SGX local/remote attestation is needed for these “relatives” (i.e., no need for explicitly accessing `/dev/attestation/` files).
>
> * Graphene enclaves that are not “relatives”: these are just two Graphene instances started completely separately (e.g., you start `graphene-sgx app1` in one bash terminal and `graphene-sgx app2` in another bash terminal). In this case, even if these Graphene enclaves run on the same machine, there is no automatic attestation/connection between these enclaves (well, obviously, they were started separately and don’t even know about each other). In this case, if you want to connect these enclaves, you need to explicitly create a socket between them (just like you would do for normal applications). And in this case, you *need* to add SGX local/remote attestation and also *explicit encryption* (e.g., wrap your socket connections in TLS sessions). And for this case, you need to *explicitly do SGX attestation* via `/dev/attestation/` files.
> * Mid-level RA-TLS library; this is easier but still requires some additional code and building steps.
> * High-level Secret Provisioning library; this one is the easiest but provides only some limited functionality.
> To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com<https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com?utm_medium=email&utm_source=footer>.
Borys
On 9/8/21 4:54 PM, Kuvaiskii, Dmitrii wrote:
> Dear Taylor,
>
> There are two separate ways of communication between Graphene processes (SGX enclaves):
>
>
>
> * Graphene enclaves that are not “relatives”: these are just two Graphene instances started completely separately (e.g., you start `graphene-sgx app1` in one bash terminal and `graphene-sgx app2` in another bash terminal). In this case, even if these Graphene enclaves run on the same machine, there is no automatic attestation/connection between these enclaves (well, obviously, they were started separately and don’t even know about each other). In this case, if you want to connect these enclaves, you need to explicitly create a socket between them (just like you would do for normal applications). And in this case, you *need* to add SGX local/remote attestation and also *explicit encryption* (e.g., wrap your socket connections in TLS sessions). And for this case, you need to *explicitly do SGX attestation* via `/dev/attestation/` files.
>
> And of course, if you need SGX remote attestation, you need to use one of the following:
>
>
> * Low-level `/dev/attestation` primitives; this is cumbersome but very powerful, you control everything.
> And of course, if you need SGX remote attestation, you need to use one of the following:
>
>
> * Mid-level RA-TLS library; this is easier but still requires some additional code and building steps.
> * High-level Secret Provisioning library; this one is the easiest but provides only some limited functionality.
>
> --
> Dmitrii
>
> From: graphene...@googlegroups.com <graphene...@googlegroups.com> On Behalf Of Taylor A. Hardin
> Sent: Wednesday, September 8, 2021 4:43 PM
> To: Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io
> Subject: Re: [graphene-support] Fork and Execv
>
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://github.com/gramineproject/graphene/blob/master/LibOS/shim/test/regression/attestation.c>, the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
> --
> Dmitrii
>
> From: graphene...@googlegroups.com <graphene...@googlegroups.com> On Behalf Of Taylor A. Hardin
> Sent: Wednesday, September 8, 2021 4:43 PM
> To: Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io
> Subject: Re: [graphene-support] Fork and Execv
>
>
> In the ra-tls source code for the ra-tls-secret-prov example, however, it looks like secrets are provisioned via an mbedtls session that gets configured after remote attestation. Does that mean I should also provision secrets via TLS for local attestations as well (i.e., for two enclaves running on the same machine)?
>
> I think I already have everything I need now that I know fork() creates a new enclave and execv() replaces the process in the current enclave; I was just curious as to what purposes /dev/attestation/user_report_data and /dev/target_info serve though.
>
>
> Taylor
> ________________________________
> From: Borys <bor...@invisiblethingslab.com<mailto:bor...@invisiblethingslab.com>>
> In the ra-tls source code for the ra-tls-secret-prov example, however, it looks like secrets are provisioned via an mbedtls session that gets configured after remote attestation. Does that mean I should also provision secrets via TLS for local attestations as well (i.e., for two enclaves running on the same machine)?
>
> I think I already have everything I need now that I know fork() creates a new enclave and execv() replaces the process in the current enclave; I was just curious as to what purposes /dev/attestation/user_report_data and /dev/target_info serve though.
>
>
> Taylor
> ________________________________
> Sent: Wednesday, September 8, 2021 9:48 AM
> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu<mailto:Taylor.A....@dartmouth.edu>>; sup...@graphene-project.io<mailto:sup...@graphene-project.io> <sup...@graphene-project.io<mailto:sup...@graphene-project.io>>
> Subject: Re: [graphene-support] Fork and Execv
>
> Graphene emulates Linux on a syscall level (basically hijacks every syscall instruction, be it via modified libc or directly emulating it). system() is a function from C standard library and as such does not differ from any other code run, from the Graphene's point of view.
> Such emulation allows us to transparently handle everything without cooperation from the application (hence you can run unmodified ELF binaries). This means you don't need to worry about attestation (or anything else) when doing fork or execve syscalls (directly or by using wrapper functions, like system()).
>
> "/dev/attestation" subsystem needs to be used when doing *remote attestation*, it's not used for local attestation (and even if it was, you wouldn't have to worry about it, since it's done automatically by Graphene).
> For local tests you can ignore remote attestation, it's needed when you want to safely run the application on another, untrusted machine. You can check our RA-TLS example for more information.
>
> Borys
>
> On 9/8/21 3:34 PM, Taylor A. Hardin wrote:
>> Hi Borys,
>>
>> Thank you very much for the response. Would the call system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
>>
>> It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:
>>
>> 1. Have program A write the secrets to dev/attestation/user_report_data
>> 2. Have program A call fork
>> 3. Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
>> 4. Have the child process call execv and pass the secret to program B as a command line argument
>>
>> Taylor
>> ________________________________
>> From: Borys <bor...@invisiblethingslab.com<mailto:bor...@invisiblethingslab.com>>
>
> Graphene emulates Linux on a syscall level (basically hijacks every syscall instruction, be it via modified libc or directly emulating it). system() is a function from C standard library and as such does not differ from any other code run, from the Graphene's point of view.
> Such emulation allows us to transparently handle everything without cooperation from the application (hence you can run unmodified ELF binaries). This means you don't need to worry about attestation (or anything else) when doing fork or execve syscalls (directly or by using wrapper functions, like system()).
>
> "/dev/attestation" subsystem needs to be used when doing *remote attestation*, it's not used for local attestation (and even if it was, you wouldn't have to worry about it, since it's done automatically by Graphene).
> For local tests you can ignore remote attestation, it's needed when you want to safely run the application on another, untrusted machine. You can check our RA-TLS example for more information.
>
> Borys
>
> On 9/8/21 3:34 PM, Taylor A. Hardin wrote:
>> Hi Borys,
>>
>> Thank you very much for the response. Would the call system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
>>
>> It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:
>>
>> 1. Have program A write the secrets to dev/attestation/user_report_data
>> 2. Have program A call fork
>> 3. Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
>> 4. Have the child process call execv and pass the secret to program B as a command line argument
>>
>> Taylor
>> ________________________________
>> Sent: Wednesday, September 8, 2021 7:24 AM
>> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu<mailto:Taylor.A....@dartmouth.edu>>; sup...@graphene-project.io<mailto:sup...@graphene-project.io> <sup...@graphene-project.io<mailto:sup...@graphene-project.io>>
>> Subject: Re: [graphene-support] Fork and Execv
>>
>> Hello,
>> In the fork case the new process will run in a separate enclave that will be locally attested. All secrets/data are sent via TLS encrypted channel after the attestation.
>> In case of execve, the new program is run in the same enclave, so yes, execve arguments are secure.
>>
>> Borys
>>
>> On 9/7/21 9:28 PM, Taylor A. Hardin wrote:
>>> Hello,
>>>
>>> I had a question regarding the use of the fork and execv system calls with graphene-sgx. That is, if I have a program running under graphene-sgx (e.g., graphene-sgx ./my_program) which uses either of these system calls, will the new process execute within the same enclave that my_program is in or a separate enclave? Or will it not be executed in an enclave at all? If the second process is being placed into its own enclave, are the command line arguments passed with execv secure?
>>>
>>>
>>> Thanks,
>>> Taylor
>>>
> --
> You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to graphene-suppo...@googlegroups.com<mailto:graphene-suppo...@googlegroups.com>.
>>
>> Hello,
>> In the fork case the new process will run in a separate enclave that will be locally attested. All secrets/data are sent via TLS encrypted channel after the attestation.
>> In case of execve, the new program is run in the same enclave, so yes, execve arguments are secure.
>>
>> Borys
>>
>> On 9/7/21 9:28 PM, Taylor A. Hardin wrote:
>>> Hello,
>>>
>>> I had a question regarding the use of the fork and execv system calls with graphene-sgx. That is, if I have a program running under graphene-sgx (e.g., graphene-sgx ./my_program) which uses either of these system calls, will the new process execute within the same enclave that my_program is in or a separate enclave? Or will it not be executed in an enclave at all? If the second process is being placed into its own enclave, are the command line arguments passed with execv secure?
>>>
>>>
>>> Thanks,
>>> Taylor
>>>
> --
> You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com<https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com?utm_medium=email&utm_source=footer>.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Taylor A. Hardin
Sep 8, 2021, 11:08:22 AM9/8/21
to Kuvaiskii, Dmitrii, Borys, sup...@graphene-project.io
Hi Kuvaiskii,
Thanks for the reply; it answered some of the concerns I had regarding communication between graphene enclave instances. Just to reiterate: if I start a program with
graphene-sgx ./programA and within that program fork and execv another program
./programB then I can be assured that (1) the execv commandline arguments to programB are secure and (2) if I open a pipe between A and B that the pipe is encrypted?Please don't try connecting "unrelated" Graphene enclaves running on one machine, it's a footgun. You can easily spawn multiple processes in one Graphene "instance"/enclave using a simple wrapper (in bash,python,C, whatever).
Borys
responed while I was writing this email. I assume he is recommending against connecting unrelated instances (i.e.,
graphene-sgx ./programA and graphene-sgx ./programB) because I will have to use the low-level attestation primitives which I am likely to use incorrectly?
Taylor
From: Kuvaiskii, Dmitrii <dmitrii....@intel.com>
Sent: Wednesday, September 8, 2021 10:54 AM
To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io <sup...@graphene-project.io>
Subject: RE: [graphene-support] Fork and Execv
Sent: Wednesday, September 8, 2021 10:54 AM
To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io <sup...@graphene-project.io>
Subject: RE: [graphene-support] Fork and Execv
Borys
Sep 8, 2021, 11:14:14 AM9/8/21
to Taylor A. Hardin, Kuvaiskii, Dmitrii, sup...@graphene-project.io
Yes and there is literally 0 advantages of doing so (connecting unrelated instances) over spawning processes from one instance.
Borys
On 9/8/21 5:08 PM, Taylor A. Hardin wrote:
> Hi Kuvaiskii,
>
> Thanks for the reply; it answered some of the concerns I had regarding communication between graphene enclave instances. Just to reiterate: if I start a program with graphene-sgx ./programA and within that program fork and execv another program ./programB then I can be assured that (1) the execv commandline arguments to programB are secure and (2) if I open a pipe between A and B that the pipe is encrypted?
> Please don't try connecting "unrelated" Graphene enclaves running on one machine, it's a footgun. You can easily spawn multiple processes in one Graphene "instance"/enclave using a simple wrapper (in bash,python,C, whatever).
> Borys responed while I was writing this email. I assume he is recommending against connecting unrelated instances (i.e., graphene-sgx ./programA and graphene-sgx ./programB) because I will have to use the low-level attestation primitives which I am likely to use incorrectly?
>
>
> Taylor
>
> ________________________________
> From: Kuvaiskii, Dmitrii <dmitrii....@intel.com>
> Sent: Wednesday, September 8, 2021 10:54 AM
> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io <sup...@graphene-project.io>
> Subject: RE: [graphene-support] Fork and Execv
>
>
> Dear Taylor,
>
>
>
> There are two separate ways of communication between Graphene processes (SGX enclaves):
>
>
> * Graphene enclaves that are “relatives”: these are parents, children, grandchildren, etc, created via fork/exec family of system calls. These “relatives” Graphene enclaves automatically and transparently SGX-attest each other and automatically and transparently encrypt all traffic between them (including all traffic on signals/pipes/UNIX domain sockets that connect these “relatives”). No explicit SGX local/remote attestation is needed for these “relatives” (i.e., no need for explicitly accessing `/dev/attestation/` files).
>
> * Graphene enclaves that are not “relatives”: these are just two Graphene instances started completely separately (e.g., you start `graphene-sgx app1` in one bash terminal and `graphene-sgx app2` in another bash terminal). In this case, even if these Graphene enclaves run on the same machine, there is no automatic attestation/connection between these enclaves (well, obviously, they were started separately and don’t even know about each other). In this case, if you want to connect these enclaves, you need to explicitly create a socket between them (just like you would do for normal applications). And in this case, you *need* to add SGX local/remote attestation and also *explicit encryption* (e.g., wrap your socket connections in TLS sessions). And for this case, you need to *explicitly do SGX attestation* via `/dev/attestation/` files.
> * Mid-level RA-TLS library; this is easier but still requires some additional code and building steps.
> * High-level Secret Provisioning library; this one is the easiest but provides only some limited functionality.
> To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fgraphene-support%2FMN2PR03MB4911E166FFC370CAFA103BA497D49%2540MN2PR03MB4911.namprd03.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667097648002670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HLPjtPAVj9z97cNXNRXt0oE3xmx35yb8Ir%2ByM1GncXI%3D&reserved=0>.
Borys
On 9/8/21 5:08 PM, Taylor A. Hardin wrote:
> Hi Kuvaiskii,
>
> Thanks for the reply; it answered some of the concerns I had regarding communication between graphene enclave instances. Just to reiterate: if I start a program with graphene-sgx ./programA and within that program fork and execv another program ./programB then I can be assured that (1) the execv commandline arguments to programB are secure and (2) if I open a pipe between A and B that the pipe is encrypted?
> Please don't try connecting "unrelated" Graphene enclaves running on one machine, it's a footgun. You can easily spawn multiple processes in one Graphene "instance"/enclave using a simple wrapper (in bash,python,C, whatever).
> Borys responed while I was writing this email. I assume he is recommending against connecting unrelated instances (i.e., graphene-sgx ./programA and graphene-sgx ./programB) because I will have to use the low-level attestation primitives which I am likely to use incorrectly?
>
>
> Taylor
>
> ________________________________
> From: Kuvaiskii, Dmitrii <dmitrii....@intel.com>
> Sent: Wednesday, September 8, 2021 10:54 AM
> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu>; Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io <sup...@graphene-project.io>
> Subject: RE: [graphene-support] Fork and Execv
>
>
> Dear Taylor,
>
>
>
> There are two separate ways of communication between Graphene processes (SGX enclaves):
>
>
>
> * Graphene enclaves that are not “relatives”: these are just two Graphene instances started completely separately (e.g., you start `graphene-sgx app1` in one bash terminal and `graphene-sgx app2` in another bash terminal). In this case, even if these Graphene enclaves run on the same machine, there is no automatic attestation/connection between these enclaves (well, obviously, they were started separately and don’t even know about each other). In this case, if you want to connect these enclaves, you need to explicitly create a socket between them (just like you would do for normal applications). And in this case, you *need* to add SGX local/remote attestation and also *explicit encryption* (e.g., wrap your socket connections in TLS sessions). And for this case, you need to *explicitly do SGX attestation* via `/dev/attestation/` files.
>
>
>
> And of course, if you need SGX remote attestation, you need to use one of the following:
>
>
> * Low-level `/dev/attestation` primitives; this is cumbersome but very powerful, you control everything.
>
>
> And of course, if you need SGX remote attestation, you need to use one of the following:
>
>
> * Mid-level RA-TLS library; this is easier but still requires some additional code and building steps.
> * High-level Secret Provisioning library; this one is the easiest but provides only some limited functionality.
>
>
>
> --
>
> Dmitrii
>
>
>
> From: graphene...@googlegroups.com <graphene...@googlegroups.com> On Behalf Of Taylor A. Hardin
> Sent: Wednesday, September 8, 2021 4:43 PM
> To: Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io
> Subject: Re: [graphene-support] Fork and Execv
>
>
>
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgramineproject%2Fgraphene%2Fblob%2Fmaster%2FLibOS%2Fshim%2Ftest%2Fregression%2Fattestation.c&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667097647992674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zwwv%2Ftb6gU%2Fm1OcGf9x2UpB80nJAIeb7CI%2FyAlWGUz8%3D&reserved=0>, the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
>
>
> --
>
> Dmitrii
>
>
>
> From: graphene...@googlegroups.com <graphene...@googlegroups.com> On Behalf Of Taylor A. Hardin
> Sent: Wednesday, September 8, 2021 4:43 PM
> To: Borys <bor...@invisiblethingslab.com>; sup...@graphene-project.io
> Subject: Re: [graphene-support] Fork and Execv
>
>
>
>
>
>
> In the ra-tls source code for the ra-tls-secret-prov example, however, it looks like secrets are provisioned via an mbedtls session that gets configured after remote attestation. Does that mean I should also provision secrets via TLS for local attestations as well (i.e., for two enclaves running on the same machine)?
>
>
>
> I think I already have everything I need now that I know fork() creates a new enclave and execv() replaces the process in the current enclave; I was just curious as to what purposes /dev/attestation/user_report_data and /dev/target_info serve though.
>
>
>
>
>
> Taylor
>
> ________________________________
>
>
>
> In the ra-tls source code for the ra-tls-secret-prov example, however, it looks like secrets are provisioned via an mbedtls session that gets configured after remote attestation. Does that mean I should also provision secrets via TLS for local attestations as well (i.e., for two enclaves running on the same machine)?
>
>
>
> I think I already have everything I need now that I know fork() creates a new enclave and execv() replaces the process in the current enclave; I was just curious as to what purposes /dev/attestation/user_report_data and /dev/target_info serve though.
>
>
>
>
>
> Taylor
>
> ________________________________
>
> From: Borys <bor...@invisiblethingslab.com<mailto:bor...@invisiblethingslab.com>>
> Sent: Wednesday, September 8, 2021 9:48 AM
> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu<mailto:Taylor.A....@dartmouth.edu>>; sup...@graphene-project.io<mailto:sup...@graphene-project.io> <sup...@graphene-project.io<mailto:sup...@graphene-project.io>>
> Subject: Re: [graphene-support] Fork and Execv
>
>
>
> Graphene emulates Linux on a syscall level (basically hijacks every syscall instruction, be it via modified libc or directly emulating it). system() is a function from C standard library and as such does not differ from any other code run, from the Graphene's point of view.
> Such emulation allows us to transparently handle everything without cooperation from the application (hence you can run unmodified ELF binaries). This means you don't need to worry about attestation (or anything else) when doing fork or execve syscalls (directly or by using wrapper functions, like system()).
>
> "/dev/attestation" subsystem needs to be used when doing *remote attestation*, it's not used for local attestation (and even if it was, you wouldn't have to worry about it, since it's done automatically by Graphene).
> For local tests you can ignore remote attestation, it's needed when you want to safely run the application on another, untrusted machine. You can check our RA-TLS example for more information.
>
> Borys
>
> On 9/8/21 3:34 PM, Taylor A. Hardin wrote:
>> Hi Borys,
>>
>> Thank you very much for the response. Would the call system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
>>
>> It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:
>>
>> 1. Have program A write the secrets to dev/attestation/user_report_data
>> 2. Have program A call fork
>> 3. Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
>> 4. Have the child process call execv and pass the secret to program B as a command line argument
>>
>> Taylor
>> ________________________________
>> From: Borys <bor...@invisiblethingslab.com<mailto:bor...@invisiblethingslab.com>>
> Sent: Wednesday, September 8, 2021 9:48 AM
> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu<mailto:Taylor.A....@dartmouth.edu>>; sup...@graphene-project.io<mailto:sup...@graphene-project.io> <sup...@graphene-project.io<mailto:sup...@graphene-project.io>>
> Subject: Re: [graphene-support] Fork and Execv
>
>
>
> Graphene emulates Linux on a syscall level (basically hijacks every syscall instruction, be it via modified libc or directly emulating it). system() is a function from C standard library and as such does not differ from any other code run, from the Graphene's point of view.
> Such emulation allows us to transparently handle everything without cooperation from the application (hence you can run unmodified ELF binaries). This means you don't need to worry about attestation (or anything else) when doing fork or execve syscalls (directly or by using wrapper functions, like system()).
>
> "/dev/attestation" subsystem needs to be used when doing *remote attestation*, it's not used for local attestation (and even if it was, you wouldn't have to worry about it, since it's done automatically by Graphene).
> For local tests you can ignore remote attestation, it's needed when you want to safely run the application on another, untrusted machine. You can check our RA-TLS example for more information.
>
> Borys
>
> On 9/8/21 3:34 PM, Taylor A. Hardin wrote:
>> Hi Borys,
>>
>> Thank you very much for the response. Would the call system() behave the same way? It's my understanding that it uses a combination of fork and execv to spawn a new program while allowing the current program to continue executing.
>>
>> It sounds like the local attestation and secret provisioning that happens during fork call is handled by low-level graphene code; does this mean that to provision secrets I should first write to dev/attestation/user_report_data before calling fork? Specifically, if I have program A executing and wish to then spawn program B with some secrets provisioned from A, then I would:
>>
>> 1. Have program A write the secrets to dev/attestation/user_report_data
>> 2. Have program A call fork
>> 3. Have the child process retrieve the provisioned secret (how do they retrieve the secret?)
>> 4. Have the child process call execv and pass the secret to program B as a command line argument
>>
>> Taylor
>> ________________________________
>> Sent: Wednesday, September 8, 2021 7:24 AM
>> To: Taylor A. Hardin <Taylor.A....@dartmouth.edu<mailto:Taylor.A....@dartmouth.edu>>; sup...@graphene-project.io<mailto:sup...@graphene-project.io> <sup...@graphene-project.io<mailto:sup...@graphene-project.io>>
>> Subject: Re: [graphene-support] Fork and Execv
>>
>> Hello,
>> In the fork case the new process will run in a separate enclave that will be locally attested. All secrets/data are sent via TLS encrypted channel after the attestation.
>> In case of execve, the new program is run in the same enclave, so yes, execve arguments are secure.
>>
>> Borys
>>
>> On 9/7/21 9:28 PM, Taylor A. Hardin wrote:
>>> Hello,
>>>
>>> I had a question regarding the use of the fork and execv system calls with graphene-sgx. That is, if I have a program running under graphene-sgx (e.g., graphene-sgx ./my_program) which uses either of these system calls, will the new process execute within the same enclave that my_program is in or a separate enclave? Or will it not be executed in an enclave at all? If the second process is being placed into its own enclave, are the command line arguments passed with execv secure?
>>>
>>>
>>> Thanks,
>>> Taylor
>>>
>
> --
> You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to graphene-suppo...@googlegroups.com<mailto:graphene-suppo...@googlegroups.com>.
>>
>> Hello,
>> In the fork case the new process will run in a separate enclave that will be locally attested. All secrets/data are sent via TLS encrypted channel after the attestation.
>> In case of execve, the new program is run in the same enclave, so yes, execve arguments are secure.
>>
>> Borys
>>
>> On 9/7/21 9:28 PM, Taylor A. Hardin wrote:
>>> Hello,
>>>
>>> I had a question regarding the use of the fork and execv system calls with graphene-sgx. That is, if I have a program running under graphene-sgx (e.g., graphene-sgx ./my_program) which uses either of these system calls, will the new process execute within the same enclave that my_program is in or a separate enclave? Or will it not be executed in an enclave at all? If the second process is being placed into its own enclave, are the command line arguments passed with execv secure?
>>>
>>>
>>> Thanks,
>>> Taylor
>>>
>
> --
> You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/MN2PR03MB4911E166FFC370CAFA103BA497D49%40MN2PR03MB4911.namprd03.prod.outlook.com<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fgraphene-support%2FMN2PR03MB4911E166FFC370CAFA103BA497D49%2540MN2PR03MB4911.namprd03.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667097648002670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HLPjtPAVj9z97cNXNRXt0oE3xmx35yb8Ir%2ByM1GncXI%3D&reserved=0>.
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667097648012667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MINcU4VouKyZt0%2F0USZm9M51eJS67iLsus4BM84a04U%3D&reserved=0>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Kuvaiskii, Dmitrii
Sep 8, 2021, 5:36:36 PM9/8/21
to Borys, Taylor A. Hardin, sup...@graphene-project.io
Dear Taylor,
> Just to reiterate: if I start a program with graphene-sgx ./programA and within that program fork and execv another program ./programB then I can be assured that (1) the execv commandline arguments to programB are secure and (2) if I open a pipe between A and B that the pipe is encrypted?
Yes, your understanding is exactly correct.
> I assume he is recommending against connecting unrelated instances (i.e., graphene-sgx ./programA and graphene-sgx ./programB) because I will have to use the low-level attestation primitives which I am likely to use incorrectly?
Exactly. I am also recommending against it. As Borys mentioned, it's just much simpler to use fork+execve for your set of related programs, rather than trying to connect "unrelated" programs. In the former (fork+execve) case, Graphene-SGX does all the work of (transparent) protection for you. In the latter case (connecting programs yourself), Graphene-SGX gives no protection and you have to do everything yourself (which you'll probably do wrong in the first try).
--
Dmitrii
>> <Taylor.A....@dartmouth.edu<mailto:Taylor.A.Hardin.GR@dartmouth
To unsubscribe from this group and stop receiving emails from it, send an email to graphene-suppo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/9f6e66cf-324c-9628-0643-06f8150dc21e%40invisiblethingslab.com.
> Just to reiterate: if I start a program with graphene-sgx ./programA and within that program fork and execv another program ./programB then I can be assured that (1) the execv commandline arguments to programB are secure and (2) if I open a pipe between A and B that the pipe is encrypted?
> I assume he is recommending against connecting unrelated instances (i.e., graphene-sgx ./programA and graphene-sgx ./programB) because I will have to use the low-level attestation primitives which I am likely to use incorrectly?
--
Dmitrii
To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/9f6e66cf-324c-9628-0643-06f8150dc21e%40invisiblethingslab.com.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Taylor A. Hardin
Sep 9, 2021, 1:29:06 PM9/9/21
to Kuvaiskii, Dmitrii, Borys, sup...@graphene-project.io
Great, I understand now. Thank you again, Borys and Dmitrii!
From: Kuvaiskii, Dmitrii <dmitrii....@intel.com>
Sent: Wednesday, September 8, 2021 5:36 PM
To: Borys <bor...@invisiblethingslab.com>; Taylor A. Hardin <Taylor.A....@dartmouth.edu>; sup...@graphene-project.io <sup...@graphene-project.io>
Sent: Wednesday, September 8, 2021 5:36 PM
To: Borys <bor...@invisiblethingslab.com>; Taylor A. Hardin <Taylor.A....@dartmouth.edu>; sup...@graphene-project.io <sup...@graphene-project.io>
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgramineproject%2Fgraphene%2Fblob%2Fmaster%2FLibOS%2Fshim%2Ftest%2Fregression%2Fattestation.c&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7Ceb3b5d6a51cb4b38021e08d97310bd3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667337995907046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TVoWKFBZFjxbjQIfCI3SCHC7GkH83MrbkUTet6%2BV5MM%3D&reserved=0>,
the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0,
> 3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.
> edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec94
> 46f%7C0%7C0%7C637667097648012667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MIN
> cU4VouKyZt0%2F0USZm9M51eJS67iLsus4BM84a04U%3D&reserved=0>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon
> Silva Chairperson of the Supervisory Board: Nicole Lau Registered
> Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>
--
You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to graphene-suppo...@googlegroups.com.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0,
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7Ceb3b5d6a51cb4b38021e08d97310bd3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667337995907046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1sEUKuAOzz7bM5aNwfzBs7wzGU1hliRf32fkwBsyk0E%3D&reserved=0
<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7Ceb3b5d6a51cb4b38021e08d97310bd3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667337995907046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1sEUKuAOzz7bM5aNwfzBs7wzGU1hliRf32fkwBsyk0E%3D&reserved=0>
Taylor A. Hardin
Sep 16, 2021, 4:22:23 PM9/16/21
to Kuvaiskii, Dmitrii, Borys, sup...@graphene-project.io
Hello again 🙂
I've got child process and pipes working in graphene and have now begun looking at attestation.
My question regarding the attestation code in ra-tls is: how do I generate a quote? From what I can tell, the ra-tls code loads in an x509 cert
that already contains a pre-generated quote; nowhere in the ra-tls code do I see code for generating a quote
at the time the program is running. Would I have to use some of the lower-level functions such as
sgx_get_quote in Pal/src/host/Linux-SGX/tools/sgx_attest.h to generate quotes at runtime?
Taylor
From: Kuvaiskii, Dmitrii <dmitrii....@intel.com>
Sent: Wednesday, September 8, 2021 5:36 PM
To: Borys <bor...@invisiblethingslab.com>; Taylor A. Hardin <Taylor.A....@dartmouth.edu>; sup...@graphene-project.io <sup...@graphene-project.io>
> Ok, the shim part makes sense but I am still a little confused when it comes to secret provisioning and attestation. In the regression test for attestation<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgramineproject%2Fgraphene%2Fblob%2Fmaster%2FLibOS%2Fshim%2Ftest%2Fregression%2Fattestation.c&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7Ceb3b5d6a51cb4b38021e08d97310bd3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667337995907046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TVoWKFBZFjxbjQIfCI3SCHC7GkH83MrbkUTet6%2BV5MM%3D&reserved=0>,
the local attestation function writes custom data to /dev/attestation/user_report_data which appears to be included in the report and later verified by verify_report_mac. So, I'm wondering, is this how you would provision a secret during local attestation?
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0,
> 3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.
> edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec94
> 46f%7C0%7C0%7C637667097648012667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MIN
> cU4VouKyZt0%2F0USZm9M51eJS67iLsus4BM84a04U%3D&reserved=0>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon
> Silva Chairperson of the Supervisory Board: Nicole Lau Registered
> Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>
--
You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to graphene-suppo...@googlegroups.com.
> edu%7C14fdc08a789c406c0e2f08d972d8a29f%7C995b093648d640e5a31ebf689ec94
> 46f%7C0%7C0%7C637667097648012667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MIN
> cU4VouKyZt0%2F0USZm9M51eJS67iLsus4BM84a04U%3D&reserved=0>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon
> Silva Chairperson of the Supervisory Board: Nicole Lau Registered
> Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>
--
You received this message because you are subscribed to the Google Groups "Graphene Support Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to graphene-suppo...@googlegroups.com.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0,
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7Ceb3b5d6a51cb4b38021e08d97310bd3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667337995907046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1sEUKuAOzz7bM5aNwfzBs7wzGU1hliRf32fkwBsyk0E%3D&reserved=0
<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intel.de%2F&data=04%7C01%7CTaylor.A.Hardin.GR%40dartmouth.edu%7Ceb3b5d6a51cb4b38021e08d97310bd3e%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637667337995907046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1sEUKuAOzz7bM5aNwfzBs7wzGU1hliRf32fkwBsyk0E%3D&reserved=0>
Kuvaiskii, Dmitrii
Sep 17, 2021, 2:52:35 AM9/17/21
to Taylor A. Hardin, Borys, sup...@graphene-project.io
RTFM 😊 https://graphene.readthedocs.io/en/latest/attestation.html#low-level-dev-attestation-interface
Graphene (which is by the way renamed to Gramine now) provides the low-level interface in the form of pseudo-files under `/dev/attestation` (this directory exists *only under Graphene*, so it’s also a good way to check whether the app runs inside Graphene or normally).
Also see a quick example (actually, our regression test) on how to use it in C:
- https://github.com/gramineproject/gramine/blob/master/LibOS/shim/test/regression/attestation.c
- https://github.com/gramineproject/gramine/blob/master/LibOS/shim/test/regression/attestation.manifest.template
You *don’t* need to use RA-TLS if you want your app to produce SGX quotes. RA-TLS is a higher-level interface (again, check the first link).
To view this discussion on the web visit https://groups.google.com/d/msgid/graphene-support/MN2PR03MB491153848FF7D339F32A9D5597DC9%40MN2PR03MB4911.namprd03.prod.outlook.com.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Taylor A. Hardin
Sep 20, 2021, 1:11:35 PM9/20/21
to Kuvaiskii, Dmitrii, Borys, sup...@graphene-project.io
Ahhhh I went back through the RA-TLS code and found where it was generating the quotes with the lower-level library code. Thanks again!
From: Kuvaiskii, Dmitrii <dmitrii....@intel.com>
Sent: Friday, September 17, 2021 2:51 AM
Sent: Friday, September 17, 2021 2:51 AM
Reply all
Reply to author
Forward
0 new messages