Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Rust type to represent a valid libc::sockaddr_ll #2397

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jonatanzeidler
Copy link

@jonatanzeidler jonatanzeidler commented May 6, 2024

What does this PR do

This PR adds a SockAddrLl struct to represent a libc::socketaddr_ll with the additional guarantee of valid data, that can be made into a LinkAddr without unsafe code. See #2327, #2059 and #2396 for reference.

Checklist:

  • I have read CONTRIBUTING.md
  • I have written necessary tests and rustdoc comments
  • [ ] A change log has been added if this PR modifies nix's API

@jonatanzeidler jonatanzeidler force-pushed the from-sockaddr_ll-native branch from 9c96179 to 6a5d5fa Compare May 6, 2024 16:20
@jonatanzeidler
Copy link
Author

jonatanzeidler commented May 14, 2024

Just for clarification: Is the unsafe around constructing the LinkAddr due to the invariant (like len must match the other data) or about the potentially unsound libc types coming in via an FFI?

@asomers
Copy link
Member

asomers commented Jun 2, 2024

Just for clarification: Is the unsafe around constructing the LinkAddr due to the invariant (like len must match the other data) or about the potentially unsound libc types coming in via an FFI?

If you're referring to LinkAddr::from_raw, it must be unsafe because it reads from a raw pointer. All methods that read from a raw pointer are unsafe. And the reason that it reads from a raw pointer is because that's how many C APIs, like getpeeraddr provide sockaddrs. C basically treats the various sockaddr types as a variable length tagged union.

This PR's implementation of From<SockAddrLl> is incorrect. It doesn't guarantee valid data. It doesn't validate the family or length fields, so it's easy to construct an invalid sockaddr_ll. Is all you want a safe constructor for sockaddr_ll? If so, I suggest you simply add one. There's no need for a new type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants