Re: Re: [PATCH v12 00/18] Enable FSGSBASE instructions

From: Don Porter
Date: Fri May 22 2020 - 16:14:27 EST


On 5/19/20 12:48 PM, Jarkko Sakkinen wrote:
On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> writes:
On Mon, 2020-05-18 at 08:34 -0700, Andi Kleen wrote:
Yes, for SGX this is functional feature because enclave entry points,
thread control structures (aka TCS's), reset FSBASE and GSBASE registers
to fixed (albeit user defined) values. And syscall's can be done only
outside of enclave.

This is a required feature for fancier runtimes (such as Graphene).

Can you please explain a bit more? What do they need GS for?

Apparently, uses only wrfsbase:

https://raw.githubusercontent.com/oscarlab/graphene/master/Pal/src/host/Linux-SGX/db_misc.c

I'm not too familiar with the codebase yet but by reading some research
papers in the past the idea is to multiplex one TCS for multiple virtual
threads inside the enclave.

E.g. TCS could represent a vcpu for a libos type of container and on
entry would pick on a thread and set fsbase accordingly for a thread
control block.

That justifies to write books which recommend to load a kernel module
which creates a full unpriviledged root hole. I bet none of these papers
ever mentioned that.

Fully agree that oot lkm for this is a worst idea ever.

That's why I want to help with this.

/Jarkko


>

Hi all, and apologies for the resend,

I wanted to clarify that we never intended the Graphene kernel module you mention for production use, as well as to comment in support of this patch.

Setting the fs register in userspace is an essential feature for running legacy code in SGX. We have been following LKML discussions on this instruction for years, and hoping this feature would be supported by Linux, so that we can retire this module. To our knowledge, every SGX library OS has a similar module, waiting for this or a similar patch to be merged into Linux. This indicates a growing user base that needs this instruction.

Just for some history, Graphene was originally a research proof-of-concept that started in my lab, and has since received substantial contributions as an open source project from companies including Intel. This code base is explicitly not intended or ready for production use at this point, as it is still missing essential features.

We wrote the kernel module as a way to get something working quickly, so that we could focus on studying more difficult aspects of porting code to SGX. We had always assumed that the Linux community would eventually offer a correct and safe mechanism to enable this instruction, but we generally err on the side of publishing code we write for research studies as open source in the interest of supporting reproducibility and further science.

Nonetheless, Graphene is moving towards adoption in production systems, and we are actively working to make the code base secure and robust. This issue has been on our to-do list before a production release. It would certainly make our lives easier to deprecate our module and just use a robust, in-kernel implementation.

All the best,
Don Porter
Graphene Maintainer
https://grapheneproject.io/