Ryan Levick (rylev) (Dec 06 2023 at 15:26): Ryan Levick (rylev) (Dec 06 2023 at 15:26):Was looking at fixing the TODO left by @Badeend in the UDP implementation for checking permissions that datagram streams are actually allowed to connect to the remote address. However, to know which addresses we're allowed to connect with we need access to the network resource, but I don't believe we every have access to network at any point in creating datagram streams. Am I missing something or is this a bug in the udp wit interface?
Dan Gohman (Dec 06 2023 at 15:33):Unless I'm missing something, that appears to be a bug. Each outgoing-datagram can have an ip-socket-address to be sent to, but there's no network argument on the send.
Dave Bakker (badeend) (Dec 06 2023 at 15:33):Every UDP socket need to be bound to a network+local address using bind before you can call any stream-related method.
Dan Gohman (Dec 06 2023 at 15:34):Ah, and then all outgoing-datagrams are associated with that network? That makes sense.
Dave Bakker (badeend) (Dec 06 2023 at 15:34):Yup
Ryan Levick (rylev) (Dec 06 2023 at 15:34):But can't you change the upstream address?
stream: func(remote-address: option<ip-socket-address>)-> result<tuple<incoming-datagram-stream, outgoing-datagram-stream>, error-code>;
The local address is bound exactly once, indeed. But the socket can be used to send&receive to/from many remote addresses
Ryan Levick (rylev) (Dec 06 2023 at 15:37):And wouldn't those remote addresses need to be validated against the network?
Dave Bakker (badeend) (Dec 06 2023 at 15:37):Yes. That's what the TODO comments are for
Dave Bakker (badeend) (Dec 06 2023 at 15:39):So I guess you need to find a way to smuggle the network reference into the datagram streams
Ryan Levick (rylev) (Dec 06 2023 at 15:39):Ok :-) so we're back to my original question. In order to check against the network, we need a handle to the network resource which we never have when creating a stream.
Ryan Levick (rylev) (Dec 06 2023 at 15:41):Ok so it's not a bug in the wit - we should be able to do the smuggling. The issue is that we're implementing HostUdpSocket on T: WasiView so there's not really any place for us to stick that reference currently.
Dave Bakker (badeend) (Dec 06 2023 at 15:41):Not directly at the moment, no. So the bind implementation needs to be altered to that it remembers the network reference the socket was bound to
Ryan Levick (rylev) (Dec 06 2023 at 15:43):I'm not sure what the right solution could be since it seems like we want HostUdpSocket to be implemented on anything that implements WasiView, and it doesn't seem like we want to alter WasiView to learn how to store network resource handles.
Joel Dice (Dec 06 2023 at 15:44):Could (should) you store it using WasiView::table_mut()?
Joel Dice (Dec 06 2023 at 15:45):(not sure how that would work; just a drive-by comment :)
Ryan Levick (rylev) (Dec 06 2023 at 15:46):Well the handle is in the table already, but we don't have a handle to it .
Alex Crichton (Dec 06 2023 at 16:05):There's two options for this I think, one is to make a udp socket a "child" resource of the network which means you couldn't destroy the network until after you destroyed the udp socket. Then you'd be able to store Resource<Network> in the UDP socket representation. I wouldn't advise this due to the runtime semantics of child handles.
Alternatively the Network structure could have an Arc internally and when the UDP socket is bound/created it clones that Arc and then stores it internally
Ryan Levick (rylev) (Dec 06 2023 at 17:14):FYI: https://github.com/bytecodealliance/wasmtime/pull/7648
Last updated: Nov 22 2024 at 16:03 UTC