Calling into Go

[Ross Pure]

I was looking in to the possibility of running code that is currently written in Go inside Asylo. My main question is: can this be done? I will list some things that I have tried so far without success:

• Go can be compiled into static/shared objects, so I tried doing this and adding the compiled Go object to the Bazel build. So far this has always resulted in a build error, which usually looks like it is a result of the incompatibility of the Asylo build toolchain and the one used to create the Go object.
• Modifying the install-toolchain script in the Asylo SDK. I was hoping that simply adding Go to the enabled languages for GCC, i.e. changing the configure option for the satge 2 GCC to be --enable-languages=c,c++,go would work, because then I could use the resulting version of gccgo to compile the Go code and hopefully it would be compatible with the rest of the Bazel build. However, this caused problems during the configuration (specifically, at first it complained about binutils, in particular ld, not being compiled with --with-sysroot support, then after fixing that it looked like either configuration or make failed because it couldn't locate sys/termios.h, which existed but wasn't being pointed to by any include option in the gcc calls), and I don't know enough about the Asylo toolchain and building GCC to know whether building the toolchain with support for Go is fundamentally incompatible (or whether Go code compiled with it would even be compatible with Asylo).

Thanks in advance.

[Matt Gingell]

Hi Ross,

This isn’t a scenario we’ve looked at. My suspicion is this will be quite difficult, as Asylo provides a system interface at the level of libc, whereas the golang runtime issues system calls directly. As the syscall instruction is not available inside an SGX enclave, I suspect you would just end up crashing at runtime even if you could resolve the toolchain issues you’re reporting. Without making substantial changes ito the golang runtime (see for instance os_linux.go and syscall_unix.go), and possibly adding critical syscalls to Asylo that the golang runtime requires, I don’t think this is going to work.

Looking around, I do see some examples of calling into untrusted go code running outside an enclave. See: https://github.com/rupc/go-with-intel-sgx. There’s also been some academic research work on adding SGX support at the language / runtime level which you may find interesting. See: https://github.com/epfl-dcsl/gotee.

Regards,

Matt Gingell

--
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/8a146bfb-f189-437a-b81c-55a6ea1fa3ben%40googlegroups.com.