Slashdot Mirror


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

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.

7 of 113 comments (clear)

  1. Re:"VLAs within structures" not part of C by aardvarkjoe · · Score: 4, Informative

    This is what they are referring to. Code like (from that link):

    void
    foo (int n)
    {
      struct S { int x[n]; };
    }

    --

    How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
  2. Re:"VLAs within structures" not part of C by Anonymous Coward · · Score: 2, Informative

    Looks like you are lost, buddy. This is C.
    And how does your vector BS solve the problem? Is its storage allocated on stack entirely?

  3. GCCisms by jd · · Score: 4, Informative

    The first problem is that they can be dropped from future versions of GCC. They're not part of any standard, after all.

    The second problem is that there are situations in which GCC isn't the most suitable compiler. You want to minimize hacks for each different compiler supported.

    Security is a big thing, too. It's hard to audit fundamentally unpredictable code.

    A major step forward.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:GCCisms by The+Evil+Atheist · · Score: 3, Informative

      VLAs are part of the C99 standard. It says so right in the summary, and you can look up the standard itself.

      --
      Those who do not learn from commit history are doomed to regress it.
  4. Re:Finally! by Spacelem · · Score: 2, Informative

    Acronyms are words that you pronounce, like laser (Light Amplification by Stimulated Emission of Radiation), scuba, radar, or PIN (Personal Identification Number number).

    Initialisms are words you spell out, like FBI, CIA, DNR, ECG, MRI, DVLA etc.

    A TLA is an initialism, not an acronym, so really it's not a TLA, it's a TLI. Not sure which one CAT is supposed to be though!

  5. Re:"VLAs within structures" not part of C by The+Evil+Atheist · · Score: 1, Informative

    std::vector uses the heap. VLAs are supposed to be on the stack, or at least without require separate allocation. You can't use the heap to solve all your problems when it comes to a kernel.

    --
    Those who do not learn from commit history are doomed to regress it.
  6. Re:"VLAs within structures" not part of C by Darinbob · · Score: 3, Informative

    Generally, you can get the tricky parts of the kernel done in C, then layer C++ on top of it. That's what a lot of embedded RTOS systems do. The biggest snag is the tendency of getting bloated code from developoers not aware of what C++ does behind the scenes.