auxv entries

[wintersteiger]

@davidchisnall @vtikoo: we have an SGX-LKL-specific entry for AT_HW_MODE in elf.h. I've started putting the attestation evidence into auxv as well, but I'm wondering whether this is the right place for these definitions. It looks like I can't see them from my test program; is the plan to make them available via #include <elf.h> (and my include paths are wrong) or should this go elsewhere?

[vtikoo]

Moving this and future entries into a more shareable header file sounds reasonable to me.
While adding AT_HW_CODE I didn't think of the implications of these entries being used from outside musl, and just co-located them with the existing auxv entries.

[wintersteiger]

Actually, since applications are compiled against normal-MUSL, those macros will never be visible to them. So, I think they will just have to know them, e.g. like here: https://github.com/wintersteiger/sgx-lkl/blob/0ac7f5449bc1c2c58bd2c4a5cd71c9b301c3a6f9/tests/basic/eeid-config/hello-eeid.c#L10

Is there a better solution? Should we inject an additional header file into the build? Since applications that make use of them depend on SGX-LKL by definition, can we assume that they have a copy of SGX-LKL so they can include an SGX-LKL header in their build?

[davidchisnall]

What applications need to know about these? I was under the impression that they were just there so that our userspace init code can talk to the SKR service and get keys for mounting. That code will eventually be statically linked against our musl.

[wintersteiger]

Oh yeah, that part is fine. I thought we wanted to make them available to applications as well, along with the TLS certificate, etc.