On 21.07.23 02:24, Dave Hansen wrote:
I wholeheartedly agree with the desire to spin up enclaves without the
overhead or complexity of the SDK. I think I'm the one that asked for
this test enclave in the first place. There *IS* a gap here. Those who
care about SGX would be wise to close this gap in _some_ way.
But I don't think the kernel should be the place this is done. The
kernel should not be hosting a real-world (userspace) SGX reference
implementation.
Okay, makes sense.
I'd fully support if you'd like to take the selftest code, fork it, and
maintain it. The SGX ecosystem would be better off if such a project
existed. If I can help here in some way like (trying to) release the
SGX selftest under a different license, please let me know.
Thank you! I agree this would benefit the SGX ecosystem and I'll go
ahead with further developing such a standalone fork when I find time
probably in the next month or so. For future reference, in case people
end up reading this discussion thread, I created a placeholder (atm
emtpy) repo here:
https://github.com/jovanbulck/bare-sgx
Re licensing: no need to re-license, I think GPL would be the best
license for such a project anyway.
The only patches I want for the kernel are to make the test enclave more
*obviously* insecure.
Makes sense. I'll see if I can create a new proposed minimal patch in
this spirit (e.g., removing existing register cleansing and adding an
explicit comment) to take away any misguided impression that the test
enclave would be a representative example of secure code and make its
real purpose clearer.
So, it's a NAK from me for this series. I won't support merging this
into the kernel. But at the same time, I'm very sympathetic to your
cause, and I do appreciate your effort here.
Thank you, appreciated!
