Starting this thread to continue/track the conversation in #152851:
I see. Is this specifically enabling these two cases?
Additionally, other forms may be accepted, for example service names:
fully-qualified-service-name (e.g. _example._tcp.example.com)
address:service-name (e.g. address:example)
If that's the case, I'm wondering if we should add support for those specific forms in some portable non-target-specific fashion, because those aren't things that people expect to work in general when passing host:port.
My impression @joshtriplett is that the answer is no to this: this is needed for even basic DNS resolution: connect("example.com:443") would also go through this, no need for SRV records to be involved. And since the API seems to be "pass a string back to userspace, get back a socket", there's technically arbitrary stringly-typed ABI here.
From the docs (https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#networking):
In keeping with the design goals for this specification, the networking/socket interface doesn’t use sockaddr types and doesn’t have a separate API for name resolution. Userspace can’t be trusted to do name resolution correctly, and even if it did, userspace can’t be trusted to actually connect streams to the correct address specified by the enclave. Therefore, addresses specified should merely be treated as a suggestion, and additional measures must be taken by an enclave to verify the stream is connected to the correct peer, e.g. TLS.
I don't understand this paragraph. It starts by saying that userspace can't be trusted to do name resolution or connect streams to the intended address. That seems reasonable (at all times, really, SGX isn't special here). But I don't see how not exposing a translation API between names (e.g., example.com:443) and SocketAddrs (104.18.26.120:443) would change the property here. SGX code shouldn't trust the address returned by that userspace resolve to actually be for example.com, but that is equally true of regular userspace code running in Linux: if I connect to github.com, I don't actually really need DNS to give me the right IP, I just need to verify that the TLS certificate issued to it matches the name I expected.
Can SGX folks expand on why a name resolution API isn't possible to add? What am I missing about the threat model here?
Starting this thread to continue/track the conversation in #152851:
My impression @joshtriplett is that the answer is no to this: this is needed for even basic DNS resolution: connect("example.com:443") would also go through this, no need for SRV records to be involved. And since the API seems to be "pass a string back to userspace, get back a socket", there's technically arbitrary stringly-typed ABI here.
From the docs (https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#networking):
I don't understand this paragraph. It starts by saying that userspace can't be trusted to do name resolution or connect streams to the intended address. That seems reasonable (at all times, really, SGX isn't special here). But I don't see how not exposing a translation API between names (e.g.,
example.com:443) and SocketAddrs (104.18.26.120:443) would change the property here. SGX code shouldn't trust the address returned by that userspace resolve to actually be for example.com, but that is equally true of regular userspace code running in Linux: if I connect to github.com, I don't actually really need DNS to give me the right IP, I just need to verify that the TLS certificate issued to it matches the name I expected.Can SGX folks expand on why a name resolution API isn't possible to add? What am I missing about the threat model here?