In D125142#3505767, @jfb wrote:

I think the most relevant post from @rsmith is: https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/40

He has a prototype: https://reviews.llvm.org/D79249
I assume he would like someone to pursue it further, it was a good faith attempt at not just demanding. I'd played with it and it needed a few fixes, but overall it was pretty complete. Does someone want to give it a go?

This is marked "needs revision", but I think it just needs wider review?

In D125142#3502732, @MaskRay wrote:

This cannot be committed as is. In particular, @rsmith's "We do not want to create or encourage the creation of language dialects and non-portable code," concern on https://discourse.llvm.org/t/making-ftrivial-auto-var-init-zero-a-first-class-option/55143/2 (shared by someone else) will be affected, I'd like to see that they lift their concerns.

add release notes

update with suggestions

Report flag as "unused"

In D125142#3499010, @brooks wrote:

It would be somewhat helpful as a transition aid if -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang remained as a no-op producing a warning (a generic unused argument warning would be fine).

I tested this (with D123958), and it appears to be working as intended. These two fptrs are the first and second listed, and are happily randomized:

In D123958#3459205, @aaron.ballman wrote:

I had assumed that any structure not marked for randomization would not be randomized. Based on that, I don't think inner structure objects (anonymous or otherwise) should automatically randomize their fields. WDYT?

FWIW, related problems with pskb_expand_head were seen again here:
https://github.com/ClangBuiltLinux/linux/issues/1599

I can build and boot with this. Nice! :) One issue I see is in instruction sequence ordering.

Ping; Nick, do you have a moment to rework this patch? AIUI, this is still important to getting CFI more sane for Android.

Is https://bugs.llvm.org/show_bug.cgi?id=50322 a duplicate of https://bugs.llvm.org/show_bug.cgi?id=23280 ? (Can both be closed?)

Yeah, I can confirm that many cases are improved with this patch (others are more sensitive and depend on the __bos behavior I mentioned). With the 17 kernel FORTIFY self-tests, all 17 fail without this patch. With this patch, 9 start passing. Nice!

I'm setting up to test this patch (thank you!) using my current kernel FORTIFY improvements. Right now I have a bunch of compile-time behavior selftests written:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/overflow&id=3c5221f3f4fd865a780f544b72c68f4209bd2e76

Does this address https://bugs.llvm.org/show_bug.cgi?id=50322 ? (I assume this is a new version of https://reviews.llvm.org/D92657 ?)

PoC from Sami:
https://godbolt.org/z/xfsWjhGhq

FWIW, I've tested this on a full Linux kernel build and I can confirm it's building correctly; I'm able to start my incremental FORTIFY fixes now. :) Thanks!

Is it possible to plumb fd instead of pathname? Then fchown(), fsetxattr(), etc, can all be used?

The kernel's stance on switch statements reads:

Ah! Yes, I see it now. Thanks and sorry for the noise!

Sorry if I missed something here, but why is this marked as "Closed"? It seems like the feature has still not landed (i.e. it got reverted).

In D80791#2120503, @nickdesaulniers wrote:

Might someone wish to disable PAC/BTI on an individual function, while having it on for the rest? I guess that would mean you can't call that function indirectly?

Specifically, this appears to be a legitimate bug, found by the warnings: https://bugs.llvm.org/show_bug.cgi?id=46258

Should the per-function analysis warning actually be removed? That seems like a helpful check to catch a different form of bad behavior.

In D75225#1896066, @MaskRay wrote:

In D75225#1895813, @kees wrote:

.text.* -> .text

This is not accurate: ld.bfd will keep the .text.$foo names, but place them all after the .text (it does not merge them into .text). Currently, ld.lld seems to merge them into .text. FGKASLR depends on the non-merging behavior.

I think the description is correct. I have a line // If a SECTIONS command is not specified in the code block.

Here is GNU ld's internal linker script:

.text           :
{
  *(.text.unlikely .text.*_unlikely .text.unlikely.*)
  *(.text.exit .text.exit.*)
  *(.text.startup .text.startup.*)
  *(.text.hot .text.hot.*)
  *(.text .stub .text.* .gnu.linkonce.t.*)
  /* .gnu.warning sections are handled specially by elf32.em.  */
  *(.gnu.warning)
}

(As you can see, -z keep-text-section-prefix does less than what GNU ld does. One issue with GNU ld's internal linker script is that -ffunction-sections (typical when building a libc) will cause the function exit to be reordered before others...)

Hi! What's the state of this change? Do you need help committing this?

This is not accurate: ld.bfd will keep the .text.$foo names, but place them all after the .text (it does not merge them into .text). Currently, ld.lld seems to merge them into .text. FGKASLR depends on the non-merging behavior.

Awesome! With this and D75149 my defconfig kernel build now only shows:

On my orphan checking kernel series, I'm left with only .rela_* and .rela.* getting reported, along with:

Thank you! I can confirm this fixes the problems I saw building the Linux kernel with CONFIG_UBSAN=y.

Thank you for the quick fix! I can confirm my builds with --string-debug work now. :)

For latest version see https://reviews.llvm.org/D64838

Just FYI, I can confirm a happily running arm64 kernel with CFI enabled built with this patch series. The C wrappers aren't needed and CFI is still triggering on mismatches:

Nick points out that "REQUIRES: x86-registered-target" is likely not needed.

Rebasing to monorepo...

Rebased to latest LLVM

I can confirm this fixes the Linux kernel relocation visibility problem I saw. Thank you!

Should I respin to make booleans always zero extended? I can adjust the X86 code at the same time...

For the non-X86 case: https://reviews.llvm.org/D60224

For note, this is based on https://reviews.llvm.org/D60208

What other target have their own lowering code? (Or, restated, is x86 the only target not using the generic lowering code?)

In D53765#1386975, @kees wrote:

I found a weird mis-compilation bug. Not sure if in LLVM or Clang half. Details here: https://reviews.llvm.org/D56571#1386973

In D56571#1386973, @kees wrote:

Not sure if this is the fault of the LLVM half or the Clang half, but I'm seeing mis-compilations in the current patches (llvm ca1e713fdd4fab5273b36ba6f292a844fca4cb2d with D53765.185490 and clang 01879634f01bdbfac4636ebe03b68e85b20cd664 with D56571.185489). My earlier builds were okay (llvm b1650507d25d28a03f30626843b7b133796597b4 with D53765.183738 and clang 61738985ebe78eeff6cfae7f97543d3456bac25a with D56571.181973).

I reduced the C code to this:

I found a weird mis-compilation bug. Not sure if in LLVM or Clang half. Details here: https://reviews.llvm.org/D56571#1386973

Not sure if this is the fault of the LLVM half or the Clang half, but I'm seeing mis-compilations in the current patches (llvm ca1e713fdd4fab5273b36ba6f292a844fca4cb2d with D53765.185490 and clang 01879634f01bdbfac4636ebe03b68e85b20cd664 with D56571.185489). My earlier builds were okay (llvm b1650507d25d28a03f30626843b7b133796597b4 with D53765.183738 and clang 61738985ebe78eeff6cfae7f97543d3456bac25a with D56571.181973).