You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks the refactoring of sockaddr handling and addresses the problems encountered with accept_syscall.
Background:
Currently, sockaddr is initialized using the default Unix GenSockaddr borrowed from RustPOSIX, which has the largest memory space. This may cause issues with getpeername, as IPv4/IPv6 shouldn't have a path field.
It's been observed that byte-level operations should be preferred over struct-type checks.
In Linux, there are various sockaddr structures, such as sockaddr_in for IPv4 and sockaddr_in6 for IPv6. However, tracing through the PostgreSQL source code shows that PostgreSQL uses sockaddr_storage, which is cast to sockaddr when necessary. The key difference between sockaddr and sockaddr_storage is size, with sockaddr_storage being large enough to accommodate all sockaddr types.
PostgreSQL's accept syscall passes a sockaddr->family=0 with sock_len=128, making it impossible to determine the family based on size alone.
Problem:
When using accept, recvfrom, getsockname, or getpeername, issues arise because the wrong sockaddr family is being inferred. The system receives a NULLsockaddr, and the copy_out function from RustPOSIX doesn't perform any operations.
Current Patch
I made a temporary modification to accept_syscall to make RawPOSIX work for now:
Initialize a default GenSockaddr struct based on the sockaddr family received at the dispatcher stage.
Handle the UNIX path conversion within the syscall itself.
Additionally, in the copy_out function, the number of bytes to copy will be determined by comparing initaddrlen with the actual length of the structure (taking the minimum value), ensuring that no more than the reserved space is copied.
Proposed Further Solution:
To resolve this, I suggest:
Refining the GenSockAddr data structure. Directly allocate a buffer of size 128 bytes for syscalls like accept, recvfrom, getsockname, and getpeername.
Implement a new function: Pass pointers to avoid NULL values being sent to syscalls.
The text was updated successfully, but these errors were encountered:
Description:
This issue tracks the refactoring of sockaddr handling and addresses the problems encountered with
accept_syscall
.Background:
Currently,
sockaddr
is initialized using the default UnixGenSockaddr
borrowed from RustPOSIX, which has the largest memory space. This may cause issues withgetpeername
, as IPv4/IPv6 shouldn't have a path field.It's been observed that byte-level operations should be preferred over struct-type checks.
In Linux, there are various
sockaddr
structures, such assockaddr_in
for IPv4 andsockaddr_in6
for IPv6. However, tracing through the PostgreSQL source code shows that PostgreSQL uses sockaddr_storage, which is cast tosockaddr
when necessary. The key difference betweensockaddr
andsockaddr_storage
is size, withsockaddr_storage
being large enough to accommodate allsockaddr
types.PostgreSQL's
accept
syscall passes asockaddr->family=0
withsock_len=128
, making it impossible to determine the family based on size alone.Problem:
When using
accept
,recvfrom
,getsockname
, orgetpeername
, issues arise because the wrongsockaddr
family is being inferred. The system receives aNULL
sockaddr,
and thecopy_out
function from RustPOSIX doesn't perform any operations.Current Patch
I made a temporary modification to
accept_syscall
to make RawPOSIX work for now:GenSockaddr
struct based on thesockaddr
family received at the dispatcher stage.copy_out
function, the number of bytes to copy will be determined by comparinginitaddrlen
with the actual length of the structure (taking the minimum value), ensuring that no more than the reserved space is copied.Proposed Further Solution:
To resolve this, I suggest:
GenSockAddr
data structure. Directly allocate a buffer of size 128 bytes for syscalls likeaccept
,recvfrom
,getsockname
, andgetpeername
.NULL
values being sent to syscalls.The text was updated successfully, but these errors were encountered: