The Linux kernel's random-number generator (RNG) has undergone changes to improve its handling of non-string entropy sources. Previously, attempts to feed non-string data into the RNG's add_random_regular_quality() function could lead to unintended truncation or corruption. This was due to the function expecting a string and applying string-length calculations to potentially binary data. The patch series rectifies this by introducing a new field to explicitly specify the length of the input data, regardless of its type, ensuring that all provided entropy is correctly incorporated. This improves the reliability and security of the RNG by preventing the loss of potentially valuable entropy and ensuring the generator starts in a more robust state.
The Linux Weekly News article, "Some Non-String Turbulence," delves into a recent discussion on the Linux kernel mailing list concerning the utilization of fixed-size character arrays (char arrays) versus flexible string structures based on pointers and dynamic allocation within the kernel. This debate, sparked by a patch set proposing the conversion of certain char arrays to dynamically allocated strings, highlighted a complex interplay of factors related to kernel development principles. The author meticulously outlines the arguments presented by various kernel developers, focusing on the inherent trade-offs between the two approaches.
Proponents of using dynamically allocated strings, as proposed in the patch, argue for increased flexibility. They emphasize scenarios where the length of a string might not be definitively known at compile time, potentially leading to buffer overflows if a fixed-size array is employed. Dynamic allocation allows for strings to be sized appropriately at runtime, mitigating this risk. Furthermore, they point to the potential for reduced memory consumption in cases where the actual string length is significantly shorter than the maximum allocated size of a fixed-size array.
Conversely, proponents of retaining fixed-size char arrays highlight the inherent simplicity and performance advantages of this approach. Dynamic memory allocation introduces overhead, both in terms of processing time and code complexity. In a performance-critical environment like the kernel, even small performance degradations can have significant consequences. Moreover, dynamic allocation carries the risk of memory leaks if not handled meticulously. In situations where the maximum possible string length is reasonably predictable, a fixed-size array offers a more straightforward and predictable behavior, reducing the potential for errors.
The article further explores the nuanced perspectives offered within the mailing list discussion, including considerations about the specific use cases of the char arrays in question and the potential impact of the conversion on maintainability and code readability. Ultimately, the article does not present a definitive conclusion as to which approach is superior. Instead, it emphasizes the importance of carefully considering the trade-offs between flexibility, performance, and code complexity when choosing between fixed-size char arrays and dynamically allocated strings within the kernel. The article underlines the ongoing nature of this discussion and the evolving best practices within the Linux kernel development community.
Summary of Comments ( 61 )
https://news.ycombinator.com/item?id=43790855
HN commenters discuss the implications of PEP 703, which proposes making the CPython interpreter's GIL per-interpreter, not per-process. Several express excitement about the potential performance improvements, especially for multi-threaded applications. Some raise concerns about the potential for breakage in existing C extensions and the complexities of debugging in a per-interpreter GIL world. Others discuss the trade-offs between the proposed "nogil" build and the standard GIL build, wondering about potential performance regressions in single-threaded applications. A few commenters also highlight the extensive testing and careful consideration that has gone into this proposal, expressing confidence in the core developers. The overall sentiment seems to be positive, with anticipation for the performance gains outweighing concerns about compatibility.
The Hacker News post "Some nonstring Turbulence" discussing an LWN article about potential issues stemming from non-NUL-terminated strings in the Linux kernel generated a moderate amount of discussion with 19 comments.
Several commenters focused on the historical context and rationale behind the use of NUL-terminated strings (C-strings) and the complexities introduced by alternatives. One commenter pointed out the inherent trade-offs between different string representations. C-strings, while simple, can lead to buffer overflows if not handled carefully. Pascal-style strings, which store the length upfront, avoid this but require extra memory overhead. The commenter also mentioned length-prefixed strings used in protocols, highlighting the diversity and context-dependent nature of string handling.
Another commenter delved into the specifics of the proposed "flexible string" type in the kernel, expressing skepticism about its benefits and questioning the added complexity. They argued that a flexible string type might not solve the purported problems and could even introduce new ones. They also touched on the challenges of converting existing kernel code to a new string type and the potential performance impact.
One commenter suggested that addressing the core issues leading to vulnerabilities, such as integer overflows and off-by-one errors, might be a more effective approach than introducing a new string type. They emphasized the importance of careful programming practices and robust error handling.
The performance implications of different string types were also discussed. One commenter highlighted that frequently recalculating string length could be detrimental to performance, particularly in performance-sensitive kernel code. They contrasted this with the constant-time length access of Pascal-style strings.
A few commenters shared anecdotal experiences dealing with string handling in different programming languages and systems, further illustrating the nuances and trade-offs involved. One mentioned the use of "flexible arrays" in C99 structures as a way to handle variable-length data.
A thread emerged discussing the use of
strncpyand its potential pitfalls. One commenter warned against usingstrncpyblindly, as it doesn't guarantee NUL termination and can lead to subtle bugs. They recommended careful usage and awareness of its limitations. Another commenter suggested using the OpenBSD variant ofstrlcpyas a safer alternative.Finally, one commenter questioned the overall significance of the proposed changes in the kernel and whether the benefits outweighed the potential downsides. They highlighted the existing complexity of the kernel and the importance of careful consideration before introducing new abstractions.