epoll_event cannot carry provenance on user data
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Lĩnh vực
- operating-systems
Hướng nghiên cứu
Bắt đầu từ khai báo Rust libc hiện có của epoll_event và so sánh nó với các định nghĩa C được trích dẫn trong issue. Xác định liệu libc 1.0 nên cung cấp trực tiếp union hay libc 0.2 cần các API event_data và event_ctl riêng biệt; được xem là hoàn tất khi giao diện được chọn, bảo toàn provenance, đã được triển khai và kiểm tra với các trường hợp sử dụng mang theo con trỏ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The epoll_event type is declared like this in C:
struct epoll_event {
uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
union epoll_data {
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
};
typedef union epoll_data epoll_data_t;
However, the Rust version in libc is different -- it just uses u64 for the data field. That is, unfortunately, not equivalent -- u64 cannot carry pointer provenance, so programs that want to store a pointer in data (which is quite common) need to use exposed-provenance APIs (i.e., ptr/int casts). Tokio carries some funky hacks to avoid that.
Since the C API is actually compatible with strict provenance here, it would be nice to expose that in libc as well. Given this is a breaking change it can only happen for libc 1.0 -- though it would be possible to have a separate event_data type and event_ctl declaration in its own module even in libc 0.2.
- Ngôn ngữ chính
- Rust
- Star
- 2.6k
- Fork
- 1.3k
- Merge trung bình
- 2 ngày 10 giờ
- Pull request đã merge (30 ngày)
- 26
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của rust-lang/libc
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
-
riscv32gc-unknown-linux-gnu: `timex` uses the 32-bit `c_long` layout (144 bytes), glibc's riscv32 `struct timex` is 208 bytesCó thể đã có người làm @compiler-segfault đã nhận 5 ngày trước. Đang mởC-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
rust-lang/libc#5697 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Expose `open_how` on AndroidCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
rust-lang/libc#5673 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
RTEMS: `dirfd` is not declaredCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
rust-lang/libc#5655 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
C-bug O-macos
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
rust-lang/libc#5650 · 16 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của rust-lang/libc
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
antiguru/interrexx#213 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug CLI
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
HigherOrderCO/Bend#2120 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
KNXBench-Labs/KNXBench#47 ·