Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Linux Kernel Is Now VLA-Free: A Win For Security, Less Overhead and Better For Clang (phoronix.com)

Posted by msmash on from the for-the-record dept.

With the in-development Linux 4.20 kernel, it is now effectively VLA-free. From a report: The variable-length arrays (VLAs) that can be convenient and part of the C99 standard but can have unintended consequences. VLAs allow for array lengths to be determined at run-time rather than compile time. The Linux kernel has long relied upon VLAs in different parts of the kernel -- including within structures -- but going on for months now (and years if counting the kernel Clang'ing efforts) has been to remove the usage of variable-length arrays within the kernel. The problems with them are:
1. Using variable-length arrays can add some minor run-time overhead to the code due to needing to determine the size of the array at run-time.
2. VLAs within structures is not supported by the LLVM Clang compiler and thus an issue for those wanting to build the kernel outside of GCC, Clang only supports the C99-style VLAs.
3. Arguably most importantly is there can be security implications from VLAs around the kernel's stack usage.

4 of 113 comments (clear)

  1. High vs low languages. by HeckRuler · · Score: 3, Interesting

    VLAs are an example of C becoming ever so slightly higher level. When the language does things under the hood without telling you it's just an invitation to bite you in the ass. Good purge.

    1. Re:High vs low languages. by HeckRuler · · Score: 5, Interesting

      Yes. Exactly that. It's allocating space for you. It figures out at run-time the length of your array rather than you having to do it by hand at compile-time. I didn't actually know of any security flaws this would lead to, but it stops debuggers from knowing details about calls so it obscured some information from me and pissed me off once.

  2. Good for debugging too by drnb · · Score: 3, Interesting

    It helps with debugging too. Build with two unrelated compiler systems and bugs that don't stand out in one may stand out in the other. And I am talking run-time errors not compiler warnings.

  3. C does not really have arrays by aberglas · · Score: 4, Interesting

    Just memory addresses. *Foo could be one or a few or many. Pointer arithmetic.

    So variable arrays feels odd.

    If you did not like chasing down weird memory corruption problems then you would not be using C (or C++) in the first place.

    It would have been trivial to add a little bit of sanity with syntax like

    void foo(char buf[blen], int blen)

    so a compiler could, in debug mode, check. But no, that would not be a hero's C. nor is variable length arrays.

    Incidentally, C's lack of arrays is not efficient. E.g. it is the reason we need 64 bit pointers, namely that C can only address 4 gig in 32 bit pointers. Java can access 32 gig of memory with 32 bit pointers because mallocs are aligned, and 32 gig is more than enough for the vast majority of current applications, and likely to remain so for a long time to come. Doubling your pointer size with lots of zeros is expensive, it clogs caches etc.