!ioctl: serialize nested ioctls outside of kernel#456
Conversation
Summary of ChangesHello @julianuziemblo, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly refactors the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request refactors the handling of special-case ioctl commands by moving serialization logic from kernel-space to user-space. This is a solid architectural improvement that simplifies the kernel's role and centralizes complex data handling within libphoenix. The introduction of ioctl-helper.c provides a scalable way to manage ioctl commands with complex data structures containing pointers. The changes to the ioctl function signature and implementation are well-contained and improve correctness, particularly in handling variadic arguments. I have one high-severity security-related comment regarding a potential buffer over-read.
f3e50ac to
ac66aa1
Compare
ac66aa1 to
cbd6d96
Compare
cbd6d96 to
21b189a
Compare
Unit Test Results9 553 tests 8 961 ✅ 52m 51s ⏱️ Results for commit d27bdb3. ♻️ This comment has been updated with latest results. |
21b189a to
a368c14
Compare
5ee0d1d to
5886041
Compare
5886041 to
fd5bf33
Compare
fd5bf33 to
ea82cff
Compare
ea82cff to
5e7c9cd
Compare
5e7c9cd to
5a110cd
Compare
There are some special cases where the input to the ioctl syscall is a structure with a pointer, which has to be detected and treated uniquely by the kernel. This leads to asymmetric behaviour (serialization in kernel, but deserialization in userspace) and code duplication. This change introduces simple packing and unpacking functions, which work only for the special cases, allocating memory for the whole request to be sent in the syscall and deallocating it when the syscall returns. This change also introduces function `ioctl_getPointerField` and convenience IOC_GET_PTR_FIELD macro, which allow the user to easily get the pointed-to values passed in by ioctl without knowing the inner serialization structure. JIRA: RTOS-1205
5a110cd to
e06022f
Compare
IOC* defines transferred to kernel to reduce code duplication JIRA: RTOS-1205
JIRA: RTOS-1205
e06022f to
d27bdb3
Compare
Description
Motivation and Context
Depends-On: phoenix-rtos-kernel:julianuziemblo/implement-siocethtool
Depends-On: phoenix-rtos-lwip:julianuziemblo/RTOS-1205
Depends-On: phoenix-rtos-tests:julianuziemblo/RTOS-1205
Types of changes
Serialization and deserialization is
Changed signature of ioctl syscall proxy function to:
int sys_ioctl(int fildes, unsigned long request, void *val, size_t size)This was done to pass the size of the size of the whole structure to the kernel without affecting the request variable, so we can still match on it in the device server handling the ioctl. This eliminates the need to handle special cases in the kernel: userspace serializes the ioctl, and device server unpacks it.
How Has This Been Tested?
Checklist:
Special treatment