The Linux Kernel Is Now VLA-Free: A Win For Security, Less Overhead & Better For Clang

[phoronix]

Phoronix: The Linux Kernel Is Now VLA-Free: A Win For Security, Less Overhead & Better For Clang

With the in-development Linux 4.20 kernel, it is now effectively VLA-free... The variable-length arrays (VLAs) that can be convenient and part of the C99 standard but can have unintended consequences...

http://www.phoronix.com/scan.php?pag...-Kills-The-VLA

[bachchain]

Are there any other issues with clang?

[Michael]

Are there any other issues with clang?

I think so but not entirely sure... I know AArch64 was extremely close (or good) for building the kernel with Clang, but last I was aware there were still x86_64 issues besides VLAs. There is https://wiki.linuxfoundation.org/llvmlinux but unfortunately LLVMLinux hasn't been active in years besides on ARM.

[mzs.112000]

So, does this help improve performance? I see some vague mentions that I might have a slight increase, but will there be any noticable changes for the end-user? I would imagine that networking, filesystem, and graphics would be greatly affected(in terms of security and performance).

[cb88]

So, does this help improve performance? I see some vague mentions that I might have a slight increase, but will there be any noticable changes for the end-user? I would imagine that networking, filesystem, and graphics would be greatly affected(in terms of security and performance).

It might improve perf a bit and reduce kernel size as it doesnt' need to compile in support for VLAs, however its pretty unlikly that it will have a big performance impact as any codepath that would have been slowed down much by it would have already removed it long ago.

[doublez13]

Are there any other issues with clang?

Inline assembly is the big missing feature.

[Marc Driftmeyer]

With the in-development Linux 4.20 kernel, it is now effectively VLA-free... The variable-length arrays (VLAs) that can be convenient and part of the C99 standard but can have unintended consequences.

- 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.

A clear contradiction in context.

[Marc Driftmeyer]

Inline assembly is the big missing feature.

SOURCE: https://clang.llvm.org/compatibility.html#inline-asm Inline assembly


In general, Clang is highly compatible with the GCC inline assembly extensions, allowing the same set of constraints, modifiers and operands as GCC inline assembly.

On targets that use the integrated assembler (such as most X86 targets), inline assembly is run through the integrated assembler instead of your system assembler (which is most commonly "gas", the GNU assembler). The LLVM integrated assembler is extremely compatible with GAS, but there are a couple of minor places where it is more picky, particularly due to outright GAS bugs.

One specific example is that the assembler rejects ambiguous X86 instructions that don't have suffixes. For example:
asm("add %al, (%rax)"); asm("addw $4, (%rax)"); asm("add $4, (%rax)");

Both clang and GAS accept the first instruction: because the first instruction uses the 8-bit %al register as an operand, it is clear that it is an 8-bit add. The second instruction is accepted by both because the "w" suffix indicates that it is a 16-bit add. The last instruction is accepted by GAS even though there is nothing that specifies the size of the instruction (and the assembler randomly picks a 32-bit add). Because it is ambiguous, Clang rejects the instruction with this error message:

<inline asm>:3:1: error: ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq') add $4, (%rax) ^

To fix this compatibility issue, add an explicit suffix to the instruction: this makes your code more clear and is compatible with both GCC and Clang.

[ms178]

Are there any other issues with clang?

Kernel developers with an interest in Clang use the following repo nowadays for their work to get the compiler and the Kernel into shape. Their bug tracker is a great way to follow their development and I wish more projects would use these tools to improve their work flow: https://github.com/ClangBuiltLinux/linux/issues

[Weasel]

SOURCE: https://clang.llvm.org/compatibility.html#inline-asm Inline assembly


In general, Clang is highly compatible with the GCC inline assembly extensions, allowing the same set of constraints, modifiers and operands as GCC inline assembly.

On targets that use the integrated assembler (such as most X86 targets), inline assembly is run through the integrated assembler instead of your system assembler (which is most commonly "gas", the GNU assembler). The LLVM integrated assembler is extremely compatible with GAS, but there are a couple of minor places where it is more picky, particularly due to outright GAS bugs.

One specific example is that the assembler rejects ambiguous X86 instructions that don't have suffixes. For example:
asm("add %al, (%rax)"); asm("addw $4, (%rax)"); asm("add $4, (%rax)");

Both clang and GAS accept the first instruction: because the first instruction uses the 8-bit %al register as an operand, it is clear that it is an 8-bit add. The second instruction is accepted by both because the "w" suffix indicates that it is a 16-bit add. The last instruction is accepted by GAS even though there is nothing that specifies the size of the instruction (and the assembler randomly picks a 32-bit add). Because it is ambiguous, Clang rejects the instruction with this error message:

<inline asm>:3:1: error: ambiguous instructions require an explicit suffix (could be 'addb', 'addw', 'addl', or 'addq') add $4, (%rax) ^

To fix this compatibility issue, add an explicit suffix to the instruction: this makes your code more clear and is compatible with both GCC and Clang.

Cool story, but what about actual limitations of Clang itself rather than the assembler, like the lack of asm goto or flag output operands? Were those fixed yet? (I really don't know)