[Pal/Linux-SGX] getsockname() get wrong addr and port on unbind SOCK_STREAM socket

[llly]

Description of the problem

I reproduce gramineproject/graphene#2046 on Gramine master using C code instead of Java.

Steps to reproduce

TCP server locate at 10.239.34.5:4433 and TCP client locate at 10.239.45.129
Run sample code from https://gist.github.com/listnukira/4045436

Expected results

$ ./get_ip_v1
Local ip address: 10.239.45.129
Local port : 41200
$ gramine-direct get_ip_v1
Local ip address: 10.239.45.129
Local port : 41204

Actual results

$ gramine-sgx get_ip_v1
Local ip address: 10.239.34.5
Local port : 4433

Additional information

getsockname syscall is called with connect in LibOS. getsockname in LibOS only returns the cached data.
As my description in gramineproject/graphene#2046.
The root cause is in Linux-SGX, bind_addr is NULL.

gramine/Pal/src/host/Linux-SGX/db_sockets.c

Lines 356 to 357 in f0ff094

	ret = ocall_connect(dest_addr->sa_family, sock_type(SOCK_STREAM, options), 0, /*ipv6_v6only=*/0,
	dest_addr, dest_addrlen, bind_addr, &bind_addrlen);

SGX ocall ocall_connect cannot allocate memory in enclave and doesn't call getsockname.

gramine/Pal/src/host/Linux-SGX/sgx_enclave.c

Lines 453 to 455 in f0ff094

	if (ms->ms_bind_addr && !ms->ms_bind_addr->sa_family) {
	int addrlen = ms->ms_bind_addrlen;
	ret = DO_SYSCALL(getsockname, fd, ms->ms_bind_addr, &addrlen);

.
however, Linux pal can work because bind_addr reassigned.

gramine/Pal/src/host/Linux/db_sockets.c

Lines 460 to 464 in f0ff094

	bind_addr = (struct sockaddr*)&buffer[2];
	bind_addrlen = sizeof(buffer[2]);
	/* call getsockname to get socket address */
	if ((ret = DO_SYSCALL(getsockname, fd, bind_addr, &bind_addrlen)) < 0)

I'll create a PR to fix it.

Gramine commit hash

c56a353

[dimakuv]

I'll create a PR to fix it.

@boryspoplawski is fixing the whole subsystem of sockets/networking in Gramine currently.

But if your fix is small and contained, then we can review & merge it now, to unblock such workloads.

[llly]

Yes, a small one.
Will #262 also be fixed? This getsockname issue has one more root cause that sockname of UDP cannot be retrieved right after connect, but after a sendto.

[boryspoplawski]

Yes, everything will be fixed (hopefully). The new version will is written from scratch.

[boryspoplawski]

@llly Please verify if #579 fixes this. I did with my tests.

[llly]

Yes. It fixes issue.