On Mon, Sep 21, 2020 at 10:44:19PM +0300, Jarkko Sakkinen wrote: > On Mon, Sep 21, 2020 at 09:49:48PM +0300, Jarkko Sakkinen wrote: > > To have understandable semantics you have to map error codes to > > conditions rather than opcodes. -EIO means loss of enclave in the event > > of EPC gone invalid. Enclave is already lost, that is the reason why we > > deinitialize the kernel data structures. > > > > EADD must have a different error code because nothing is actually lost > > but the failure conditions are triggered outside. -EFAULT would be > > probably the most reasonable choice for that. > > Now that I did all the changes discussed and then I remember why EADD > and EEXTEND had a common error code, and common behaviour. Obviously EADD > can also fail because of EPC reset because it depends on a valid SECS > page. > > If we cannot distinct from EADD caused by EPC loss and EADD caused by > problems with the source, it should have the same error code, and also > the enclave should be deinitialized, whenver this happens. > > So I would just revert to v38 behaviour, keeping of course the whole > check more visible in sgx_ioc_enclave_add_pages(), and just refine > the documentation better describe the whole situation. So now the behaviour is reverted back to same as it was before [*] and I refined the documenation as: " * The function deinitializes kernel data structures for enclave and returns * -EIO in any of the following conditions: * * - Enclave Page Cache (EPC), the physical memory holding enclaves, has * been invalidated. This will cause EADD and EEXTEND to fail. * - If the source address is corrupted somehow when executing EADD. " [*] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/kernel/cpu/sgx/ioctl.c /Jarkko
