Asylo changes between 0.3.4 and 0.6
119 views
Skip to first unread message
Anoop
Feb 23, 2021, 4:23:59 PM2/23/21
to Asylo Users
I'm trying to use Asylo for a use case and porting stuff from 0.3.4 to 0.6 and ran into a few questions:
- Is it possible to run the enclave binary as a standalone app in a Linux system? In version 0.3.4 we were able to compile a simple enclave binary with a “enclave_loader” target and run it as a standalone app. But in 0.6, there are a bunch of rules such as “Must be built in Asylo toolchain”. Is there a reason for this restriction? How can we avoid building the enclave in Asylo toolchain only? Or how can the enclave binary run as a standalone app with a “main”?
- In 0.3.4, we could use "enc-sim" as a config option and compile for a different backend. If we need to add a new backend, it seems like the only way now is to add something to “linux_sgx:xxx” so it can be picked up as a different backend. Seems like the old way was more extensible
- Previously we had primitives/arch and we could add different backends here. Also, there was a trusted and untrusted clean separation in “arch". But now, more of the code is moved under primitives/sgx and the boundary is not as clear. It’s mostly controlled in BUILD/bazel files. Any reason?
Dionna Amalie Glaze
Feb 23, 2021, 7:45:24 PM2/23/21
to Anoop, Asylo Users
Hi Anoop,
Enclaves have always had to be built in the Asylo toolchain, so I think what you’re facing is some incompatibility with the new transitions-based build rules.
When I changed how we structured build rules with Bazel configuration transitions, I had to mimic native.cc_binary in the build language Starlark. You can see in asylo.bzl that the transitions.cc_binary use in enclave_loader uses __ensure_static_manual to add the static linking requirement. I tried to not require static linking in order for this build rule to work, but unfortunately Starlark-based C build rules are still not 100% compatible with native C build rules and I couldn’t make this work.
A way you can work around this is to write your own targets that separate out the untrusted component and the trusted component and make them backend-specific. When you look at the definition of enclave_loader for example, you’ll see some all_backends invocation that you can just replace with a single backend. You can load some of the internally-used rules like enclave_runner_script from asylo_transitions.bzl. Your host loader target can be defined with the builtin cc_binary to avoid static linking, but you’ll need to build with a top-level backend configuration flag, like –@com_google_asylo//asylo/distrib/backend:backend=@linux_sgx//:asylo_sgx_hw
The “old way” for adding new backends was not extensible—it depended on some closed world assumptions that would not allow projects outside the Asylo namespace to define backends. If you want to define your own backend, that is a topic for a longer thread or article.
Enclaves have always had to be built in the Asylo toolchain, so I think what you’re facing is some incompatibility with the new transitions-based build rules.
When I changed how we structured build rules with Bazel configuration transitions, I had to mimic native.cc_binary in the build language Starlark. You can see in asylo.bzl that the transitions.cc_binary use in enclave_loader uses __ensure_static_manual to add the static linking requirement. I tried to not require static linking in order for this build rule to work, but unfortunately Starlark-based C build rules are still not 100% compatible with native C build rules and I couldn’t make this work.
A way you can work around this is to write your own targets that separate out the untrusted component and the trusted component and make them backend-specific. When you look at the definition of enclave_loader for example, you’ll see some all_backends invocation that you can just replace with a single backend. You can load some of the internally-used rules like enclave_runner_script from asylo_transitions.bzl. Your host loader target can be defined with the builtin cc_binary to avoid static linking, but you’ll need to build with a top-level backend configuration flag, like –@com_google_asylo//asylo/distrib/backend:backend=@linux_sgx//:asylo_sgx_hw
The “old way” for adding new backends was not extensible—it depended on some closed world assumptions that would not allow projects outside the Asylo namespace to define backends. If you want to define your own backend, that is a topic for a longer thread or article.
Regards,
-Dionna (Asylo Team)
--
Visit asylo.dev for the latest information.
---
You received this message because you are subscribed to the Google Groups "Asylo Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to asylo-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/asylo-users/281c0a09-064e-4748-aade-328ff88af9f2n%40googlegroups.com.
-Dionna Glaze, PhD (she/her)
Chong Cai
Feb 23, 2021, 8:57:29 PM2/23/21
to Dionna Amalie Glaze, Anoop, Asylo Users
Hi Anoop,
As Dionna mentioned, the reason for refactoring platform/arch to platform/primitives is some assumptions we made across the Asylo code base that were actually SGX-specific. When we started to implement backends other than SGX, we moved all backend-specific code into platform/primitives. With the current code structure, there are trusted_primitives.h and untrusted_primitives.h under platform/primitives that provide interfaces to be implemented by each backend, and each backend (SGX/dlopen) provides the implementation in their own trusted/untrusted files, With platform/primitives structure it should be more straightforward to add new backends (you can refer to dlopen backend as a simple example).
Also, the current structure largely reduces the complexity for SGX backend. You may find that we have a lot less ocalls in ocalls.cc now after the primitives refactoring.
In terms of trusted/untrusted separation, currently we prefix the files that implement the backend interfaces with trusted/untrusted (trusted_sgx/untrusted_sgx, etc), as opposed to placing them in trusted/untrusted directories. For other files, currently the easiest way to determine which side they belong to is referring to the BUILD files.
As Dionna mentioned, the reason for refactoring platform/arch to platform/primitives is some assumptions we made across the Asylo code base that were actually SGX-specific. When we started to implement backends other than SGX, we moved all backend-specific code into platform/primitives. With the current code structure, there are trusted_primitives.h and untrusted_primitives.h under platform/primitives that provide interfaces to be implemented by each backend, and each backend (SGX/dlopen) provides the implementation in their own trusted/untrusted files, With platform/primitives structure it should be more straightforward to add new backends (you can refer to dlopen backend as a simple example).
Also, the current structure largely reduces the complexity for SGX backend. You may find that we have a lot less ocalls in ocalls.cc now after the primitives refactoring.
In terms of trusted/untrusted separation, currently we prefix the files that implement the backend interfaces with trusted/untrusted (trusted_sgx/untrusted_sgx, etc), as opposed to placing them in trusted/untrusted directories. For other files, currently the easiest way to determine which side they belong to is referring to the BUILD files.
Regards,
Chong
To view this discussion on the web visit https://groups.google.com/d/msgid/asylo-users/CAAH4kHY%2BUj2FjywHV8z-0O%3DJ6%2B-gskLL0tdvQNRUnRe8p%3DLcFQ%40mail.gmail.com.
Anoop
Mar 3, 2021, 1:56:24 AM3/3/21
to Asylo Users
Thanks Dionna. I'll check if there are issues with my transitions based build rules. Good to know about the static link issues with Starlark.
I'm exploring different things with host loader and the backend configuration. Sure, I'll bring up adding another backend in a different thread with additional details.
Anoop
Mar 3, 2021, 2:02:58 AM3/3/21
to Asylo Users
Thanks Chong. Yes, I understand the motive behind moving all these components around. I'll look at how dlopen/SGX is using this new backend structure and incorporate into my change.
As a suggestion, it maybe valuable to still isolate trusted/untrusted primitives into directories, rather than just file prefixes. This will make it easier to understand instead of going through the BUILD files. But it's not a deal breaker though.
Anoop
Mar 10, 2021, 2:59:42 AM3/10/21
to Asylo Users
Chong/Dionna,
I compared the dlopen and the SGX implementation and looks like both are implemented differently in Asylo. For sgx_sim/sgx_hw the backend is defined in "linux_sgx", however for dlopen, it's just set in the path "platform/primitives/dlopen".
Secondly, the dlopen seems to work only with the example provided within the platform/primitives and is not usable with asylo/examples/xxx. Ran into a few issues porting an example to a backend implemented the same as dlopen. Need to do more work here.
So my question is, will Asylo continue to have these two as separate ways to implement backends or will it be unified?
Dionna Amalie Glaze
Mar 10, 2021, 2:17:45 PM3/10/21
to Anoop, Asylo Users
Short answer, they are unified already, it’s just that dlopen is incomplete.
The dlopen backend and the sgx backends both implement the same trusted/untrusted primitives needed to be an Asylo backend. The backend labels are all defined with the same Starlark AsyloBackendInfo provider. The reason the examples don’t work for the dlopen backend is because we haven’t implemented the full primitive interface for it. The backend isn’t meant for production, so we did just enough to demonstrate that the primitives abstraction is adequate.
Regards,
-Dionna (Asylo Team)
The dlopen backend and the sgx backends both implement the same trusted/untrusted primitives needed to be an Asylo backend. The backend labels are all defined with the same Starlark AsyloBackendInfo provider. The reason the examples don’t work for the dlopen backend is because we haven’t implemented the full primitive interface for it. The backend isn’t meant for production, so we did just enough to demonstrate that the primitives abstraction is adequate.
Regards,
-Dionna (Asylo Team)
To view this discussion on the web visit https://groups.google.com/d/msgid/asylo-users/9b696437-abe1-4392-a88c-3ba9be6ca013n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages