On Wed, Apr 29, 2020 at 8:30 AM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote: > > In closing, it is important to note that the proposed SGX driver is > > not available as a module. This effectively excludes any alternative > > implementations of the driver without replacement of the kernel at > > large. > > No it doesn't. The SGX subsytem won't allocate EPC pages unless userspace > creates an enclave, i.e. preventing unprivileged userspace from accessing > /dev/sgx/enclave will allow loading an alternative out-of-tree SGX module. > Yes, SGX sanitizes the EPC on boot, but that's arguably a good thing for > out-of-tree modules. > > And if you want to get crafty and squash in-kernel SGX altogether, boot > with "clearcpuid=<SGX_LC>" and/or "clearcpuid=<SGX>" to disable in-kernel > support entirely. SGX won't be correctly enumerated in /proc/cpuinfo > relative to the existence of an out-of-tree module, but that seems like a > very minor issue if you're running with a completely different SGX driver. > > > It also means that any platform, with SGX hardware support, > > running a kernel with this driver, has the potential for the > > security/privacy issues noted above. > > Unless I'm mistaken, /dev/sgx is root-only by default. There are far > scarier mechanisms available to root for hosing the system. > > > If key based policy management is not allowed, then the driver needs > > to be re-architected to have modular support so that alternative > > implementations or the absence of any driver support are at least > > tenable. > > As above, using an alternative implementation is teneble, albeit a bit > kludgy. It is worth noting that, if someone actualy does this, and a future kernel patch breaks it, the upstream developers are unlikely to apologize or even feel particularly bad. See, for example, the current situation with VirtualBox.
