This blog post presents a revised and more robust method for invoking raw OpenBSD system calls directly from C code, bypassing the standard C library. It improves upon a previous example by handling variable-length argument lists and demonstrating how to package those arguments correctly for system calls. The core improvement involves using assembly code to dynamically construct the system call arguments on the stack and then execute the syscall instruction. This allows for a more general and flexible approach compared to hardcoding argument handling for each specific system call. The provided code example demonstrates this technique with the getpid() system call.
This blog post, "A more robust raw OpenBSD syscall demo," delves into the intricacies of making direct system calls on OpenBSD, focusing on a more resilient approach than previously demonstrated. The author begins by recalling a prior, simpler example of invoking the gettimeofday syscall, highlighting its inherent fragility due to reliance on hardcoded offsets within the system call table. This method risks breaking with system updates that might shift these offsets.
The core improvement in this revised approach lies in dynamically resolving the syscall number for gettimeofday at runtime. This is accomplished by parsing the /usr/include/sys/syscall.h header file, specifically searching for the SYS_gettimeofday definition. The post meticulously explains the C code used to achieve this, including how it opens and reads the header file, employs a regular expression to extract the syscall number, and converts the extracted string into an integer. This number is then stored for later use in the actual system call invocation.
The author emphasizes OpenBSD's unique approach to system calls, utilizing a dedicated syscall instruction rather than a conventional interrupt mechanism like int 0x80 found in Linux. The specifics of preparing the arguments for gettimeofday on OpenBSD are detailed, including the use of a struct timeval pointer and a timezone argument (conventionally set to NULL). The blog post provides the assembly code snippet for executing the syscall instruction, emphasizing the crucial role of loading the dynamically determined syscall number into the appropriate register (%rax) before execution.
Beyond merely demonstrating a functional syscall, the post meticulously covers error handling. It showcases how to retrieve the return value from the syscall instruction (stored in %rax), and how to interpret it. Negative return values indicate an error, and the post elaborates on using the errno global variable to determine the specific error encountered. This is complemented by C code demonstrating how to check for errors and appropriately handle them, including printing informative error messages using the strerror function.
Finally, the post provides the complete, compiled C code, combining the dynamic syscall resolution with the robust error handling. This holistic example allows readers to understand the complete lifecycle of a robust raw system call on OpenBSD, from finding the syscall number to executing the call and gracefully handling potential errors. The post's emphasis on dynamic resolution underscores a more maintainable and portable approach to system calls, making it resilient to system updates that might alter syscall table offsets.
Summary of Comments ( 18 )
https://news.ycombinator.com/item?id=43340385
Several Hacker News commenters discuss the impracticality of the raw syscall demo, questioning its real-world usefulness and emphasizing that libraries like libc exist for a reason. Some appreciated the technical depth and the exploration of low-level system interaction, viewing it as an interesting educational exercise. One commenter suggested the demo could be useful for specialized scenarios like writing a dynamic linker or a microkernel. There was also a brief discussion about the performance implications and the idea that bypassing libc wouldn't necessarily result in significant speed improvements, and might even be slower in some cases. Some users also debated the portability of the code and suggested alternative methods for achieving similar results.
The Hacker News post "A more robust raw OpenBSD syscall demo" (https://news.ycombinator.com/item?id=43340385) has a modest number of comments, sparking a discussion primarily around the practicality and implications of the demonstrated technique.
One commenter points out the historical context of similar syscall techniques in older systems, mentioning how CP/M and DOS worked, highlighting the simplicity and directness of these older approaches. They suggest that while the demo might be "neat," it's not particularly novel.
Another commenter raises a concern about the portability of this method. They specifically mention the interaction with dynamic linkers like ld.so and how this approach might clash with Position Independent Executables (PIE), a common security feature in modern systems. This raises a practical barrier to using this technique in many real-world scenarios.
Building upon the portability concerns, a separate commenter notes the potential issues with signal handling and memory management, especially in multi-threaded environments. They explain that relying on the stack for argument passing in a raw syscall context can become problematic when signals interrupt execution or when threads are involved.
One commenter expresses skepticism about the "robustness" claimed in the title, arguing that true robustness in system calls necessitates proper error handling and boundary checks. They imply the demo, in its simplicity, lacks these vital aspects.
A different commenter delves into the details of OpenBSD's system call implementation, specifically mentioning the
syscall()wrapper function. They explain that this wrapper handles some of the low-level details, contrasting it with the rawer approach demonstrated in the linked blog post. This provides additional context on the standard way system calls are usually invoked in OpenBSD.Finally, a commenter pivots the discussion slightly, mentioning the security implications of directly manipulating the stack for system call arguments. They suggest that this method might create vulnerabilities, especially if the input is not properly sanitized or validated. This adds another layer of concern regarding the practicality and safety of the demonstrated technique.
In summary, the comments on the Hacker News post offer a range of perspectives, from historical context and comparisons with older systems to concerns about portability, robustness, and security. While some find the demo interesting, others express reservations about its real-world applicability and potential drawbacks.