OE/mbedTLS related memory allocation problems

[wintersteiger]

While trying to extract attestation evidence (the endorsements part to be precise) via oe_get_evidence, OE calls mbedTLS functions, which in turn call calloc and not oe_calloc (here, where mbedtls_calloc == calloc). This ends up calling sgx-lkl-musl's calloc, which ultimately complains that there's no memory because it hasn't been initialized yet. I had hoped this problem would go away after the user/kernel-space separation, but it's still there. I suspect that there could be a solution in just reordering the libraries on the command-line, but I haven't had any luck so far. What's the recommended solution for this type of problem?

[davidchisnall]

If this is from the OE version of mbedTLS, it sounds like an upstream bug, can we fix it there to define mbed_malloc as oe_malloc and similar?

[wintersteiger]

That definition is in mbedTLS and there are lots of copies of #define mbedtls_calloc calloc all over their codebase. (Yes, OE's mbedTLS, but that makes no difference here.) Most of them seem to be guarded by #ifdef MBEDTLS_PLATFORM_C, which could potentially allow us to override the relevant function names, but I have no idea what other consequences that would entail.

[wintersteiger]

Yeah, I think that's a viable solution, digging deeper.

[mikbras]

In the OE SDK, the mismatch is never a problem because oelibc forwards malloc to oe_malloc. But SGX-LKL replaces oelibc with its own version of libc in the kernel, which results in the mismatch.

Perhaps we can make oe_malloc (and friends) weak in OE, and define our own versions of these that call equivalent functions in libc.

[wintersteiger]

@mikbras sure, that sounds like a good idea. I was able to work around my immediate problem with mbedTLS, but it would be great if we could get a more general solution to this.