Invalid assumption about SocketAddrV{4,6} layout

[djc]

It looks like we're assuming that std::net::Ipv4 matches the libc sockaddr_in (same for IPv6), for example in https://github.com/quinn-rs/quinn/blob/main/quinn/src/platform/unix.rs#L357. However, the standard library never guaranteed this, and in fact is looking at changing this in rust-lang/rust#78802. We should fix our usage.

[est31]

Are older versions affected too? Would it be possible to release point releases for them? Even the very old ones? That would be really nice.

[djc]

Yeah, I went through older releases down to 0.3, which also look affected. I'm not sure it really makes sense to publish bugfix releases for anything older than 0.6, do you really those still get significant usage?

(On the other hand, if you'd be able to lend a hand in fixing/backporting, I wouldn't mind publishing some extra stuff on crates.io.)

[est31]

It would be cool if my older mimas releases still compiled. IDK how many changes a fix requires and how much the piece of code has changed between quinn releases.

[est31]

And yes, I'm willing to help.

[djc]

I'm guessing they would still compile, just get issues at run-time.

Pretty sure the relevant code hasn't changed all that much between releases.

[Matthias247]

FWIW, there seems to be an issue even today - without the Rust changes. we could observe some issues with IPv6 support where an incoming packet lead the endpoint to shut down due to an IO error.

After removing more MaybeUninits from socket layer I figured out that removing the one for socket addresses will break the receive path - decoded socket addresses get malformed. I uploaded a repro in #976

So far I don't understand why this happens, and whether there's some rust-UB issues to do having pointers of sockaddr_storage and sockaddr_in[6].

When I changed the socket address conversion to make use of https://docs.rs/socket2/0.3.19/socket2/struct.SockAddr.html#method.from_raw_parts and https://docs.rs/socket2/0.3.19/socket2/struct.SockAddr.html#method.as_std things seemed ok.

[djc]

I wonder if we could run some simple Quinn tests through Miri.

[Matthias247]

I think it doesn't do any threading. And even if it would, it would likely be too slow and not a great indicator if something is definitely wrong or if the Miri model just doesn't capture it yet.

[Ralith]

MIRI should only be needed for the unsafe platform API stuff, which we definitely could write a standalone test for. In any case, we should just replace this particular code ASAP.

[Matthias247]

A question for the fix will be whether to always convert between std and libc representations on IO calls, or whether to switch to different address types internally which have guarantees about being platform lib compatible (I guess socket2 does). public accessors (e.g. for peer addresses) could still perform a conversion to std.

Converting the representation is definitely not costly. But given that quic library does this thousands of times per second (compared to a TCP stack which does a handful conversions at connection establishment) it might be worthwhile to avoid it.

[djc]

I agree with what appears to be your assessment (that we should try to avoid the conversion on every send/recv).

[Matthias247]

Also seems like socket2 only has SocketAddr types, not IpAddr ones which make guarantees about wrapping in_addr. But maybe there is no issue, since all are plain byte arrays?