- User Since
- Feb 6 2019, 5:35 AM (172 w, 2 d)
Wed, May 11
Tue, May 10
This is marked "needs revision", but I think it just needs wider review?
Mon, May 9
add release notes
update with suggestions
Sun, May 8
Report flag as "unused"
Sat, May 7
Fri, May 6
Apr 19 2022
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:
Mar 31 2022
Feb 25 2022
FWIW, related problems with pskb_expand_head were seen again here:
Feb 8 2022
I can build and boot with this. Nice! :) One issue I see is in instruction sequence ordering.
Oct 13 2021
Ping; Nick, do you have a moment to rework this patch? AIUI, this is still important to getting CFI more sane for Android.
Sep 30 2021
Sep 27 2021
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:
Sep 17 2021
May 26 2021
PoC from Sami:
May 13 2021
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!
Feb 9 2021
Is it possible to plumb fd instead of pathname? Then fchown(), fsetxattr(), etc, can all be used?
Nov 25 2020
The kernel's stance on switch statements reads:
Aug 28 2020
Ah! Yes, I see it now. Thanks and sorry for the noise!
Aug 27 2020
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).
Jun 29 2020
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.
Mar 9 2020
Mar 4 2020
Hi! What's the state of this change? Do you need help committing this?
Feb 27 2020
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.
Feb 25 2020
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:
Feb 18 2020
Thank you! I can confirm this fixes the problems I saw building the Linux kernel with CONFIG_UBSAN=y.
Feb 17 2020
Thank you for the quick fix! I can confirm my builds with --string-debug work now. :)
Aug 15 2019
For latest version see https://reviews.llvm.org/D64838
Aug 9 2019
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:
May 30 2019
Nick points out that "REQUIRES: x86-registered-target" is likely not needed.
May 22 2019
May 20 2019
Rebasing to monorepo...
May 18 2019
Rebased to latest LLVM
Apr 5 2019
I can confirm this fixes the Linux kernel relocation visibility problem I saw. Thank you!
Apr 3 2019
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?)
Feb 6 2019
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).