On Sat, Mar 07, 2020 at 11:42:23AM -0600, Dr. Greg wrote:
On Fri, Mar 06, 2020 at 09:07:53PM +0200, Jarkko Sakkinen wrote:
Good morning, I hope the weekend is going well for everyone.
Actually many people have applaused to have a small scoped, even if not perfect, test program to look at how SGX works. One that is only dependent on glibc. None of the selftests are meant to be production peaces of code. You are getting wrong the role of the selftest in the first place.
We certainly want to be counted in the camp of those who are applausing you for making the selftests available, particularly the new VDSO setup and entry code.
We arguably have similar motivations. We architected and authored an entire SGX runtime that has as its only dependencies the MUSL C library, libelf and OpenSSL, primarily because we needed an easily auditable and low footprint SGX implementation.
Good to hear!
To the point at hand though, I'm certainly not a very smart guy so I doubt that I am able to understand the role of the selftests. We do seem to agree though that they only provide a rudimentary exercise of the driver.
The role of kselftests is not to be production code. They are somewhat adhoc pieces of code that just check that "things turn on" e.g. in a new kernel release or a new hardware platform.
We also seem to agree that the primary role of the driver is to service the needs of those of us that are building production level SGX runtime stacks. In service of that premise, it would be helpful to know if you are internally testing the driver/VDSO against enclaves of production quality, with metadata, or just the two page selftest enclave.
I do agree that a more complete test suite would be an essential thing to have. In that I'd just use the SDK and implement it outside the kernel tree.
Unfortunately I do not have time to implement such.
/Jarkko