- User Since
- Feb 6 2019, 5:35 AM (216 w, 3 d)
Feb 23 2023
This gets me all 6 reports. The details about the array and the index don't really matter for the basic metrics:
Feb 18 2023
Here's a test-case. I'd expect 6 remarks from building this:
This appears to be working for me. For before/after changes, the other half is still needed, i.e. a "accessing array of unknown size" and eventually splitting the dynamic sizing check off of that one (once -fsanitize=bounds checks __builtin_dynamic_object_size).
Feb 15 2023
This information will be useful for evaluating the coverage of the bounds checker for a given program, which in turn can help guide both improvements to the bounds checker (e.g. adding knowledge from __builtin_dynamic_object_size()) and improvements to the built code base (e.g. refactoring data structures to take advantage of known compile-time or run-time bounds that will be covered by the bounds checker). It answers the question, "What percentage of array accesses are being bounds checked?" (With the implied goal of reaching 100% going forward.)
Nov 17 2022
Looks good. Likely future work here would be to examine why the EX_IOERR exit is being exposed instead of just leaving SIGPIPE set to SIG_DFLT. But that's a separate issue entirely. :)
Oct 26 2022
The self-tests all look correct to me, so I expect it is working how I'd expect. I haven't had a chance to do kernel builds with this yet, but I'm hoping to make time soon. I'd say if others are happy, let's land it, and if anything unexpected happens we can fix those issues if they appear. :)
Oct 20 2022
This looks great to me. Thanks!
Oct 17 2022
Oct 13 2022
Oct 12 2022
Oct 11 2022
Change log typo? "but for all" should be "but not for all" ?
Oct 10 2022
Oct 7 2022
Oct 6 2022
What's the best way to test this in the kernel? I assume add ARCH_SUPPORTS_CFI_CLANG to an arch, and see what blows up? :) Have you tried this on any other arch yet?
Oct 5 2022
Oct 1 2022
Sep 30 2022
Update optional removal target release to Clang 18
Keep git-clang-format happy
Adjust subject to be more accurate ("deprecate" vs "remove")
Sep 29 2022
rebase and tweak
Excellent! Thank you for getting this prepared. Having this properly managed in the kernel means we don't have to do horrible ugly hacks to work around old 0-length arrays in UAPI (which have all been unioned with a proper flexible array now).
Thanks for all the careful consideration; I appreciate it! I'll land this tomorrow unless there are new specific objections. :)
Sep 3 2022
Aug 19 2022
Jul 13 2022
Example of the bug I want to block:
Jul 12 2022
I should clarify: I still need the =3 mode. Since sizeof() == 0 and sizeof() == error, they are being treated differently already by the compiler causing bugs in Linux. The kernel must still have a way to reject the _use_ of a  array. We cannot reject _declaration_ of them due to userspace API.
Jul 11 2022
Jun 23 2022
Jun 15 2022
Jun 14 2022
Are the presubmit build failures unrelated?
Jun 8 2022
Jun 7 2022
Thanks for working on this!
May 11 2022
May 10 2022
This is marked "needs revision", but I think it just needs wider review?
May 9 2022
add release notes
update with suggestions
May 8 2022
Report flag as "unused"
May 7 2022
May 6 2022
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
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?)
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
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 ?)
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