Skip to content

verify Clang's fortified string routines are called in the kernel #1002

Closed
Closed
verify Clang's fortified string routines are called in the kernel#1002
Assignees
kees
Labels
[FIXED][LINUX] 5.18This bug was fixed in Linux 5.18securitysecurity implication

Description

@nickdesaulniers
nickdesaulniers
opened on Apr 22, 2020

forking #979 which focuses on regressions. cc @kees @gburgessiv @m-gupta
(If we're happy with a new bug, please close #979 as fixed, otherwise close this as a dup of #979).

Kees mentions that the runtime implementations of fortified string routines in the kernel may never have been called in a clang built kernel, irrespective of regressions in #979 ? If that's so, we should figure out what we need to fix and where to leverage this technology. It's probably possible to write a kselftest to help prevent support from regressing.

Activity

  1. nickdesaulniers
    added
    securitysecurity implication
    questionQuestion asked by issue author.
    on Apr 22, 2020

  2. gburgessiv commented on Apr 24, 2020

    @gburgessiv
    gburgessiv
    on Apr 24, 2020
    Member

    Thanks for filing! I hear no discomfort with #979's resolution, so I'll close it.

    Kees mentions that the runtime implementations of fortified string routines in the kernel may never have been called in a clang built kernel, irrespective of regressions in #979 ?

    This depends on the implementation of the routine in question, but yeah, clang won't generate IR for extern inline gnu_inline functions that appear trivially recursive in a particular way. This turns at least some of the kernel's FORTIFY into a nop.

    There's some discussion of approaches we can try on #980 (comment). Kees noted that automated testing would be really nice to have here before we start trying to thread this particular needle. I agree with that. :)

  3. nathanchance commented on May 7, 2020

    @nathanchance
    nathanchance
    on May 7, 2020
    Member

    https://lore.kernel.org/lkml/20200506001453.764332-1-Jason@zx2c4.com/

  4. nathanchance commented on Apr 28, 2021

    @nathanchance
    nathanchance
    on Apr 28, 2021
    Member

    @kees had mentioned recently that he was still looking into this?

  5. kees commented on Apr 28, 2021

    @kees
    kees
    on Apr 28, 2021

    Yup, currently investigating this as a part of my memcpy work.

  6. kees
    self-assigned this
    on Apr 28, 2021

  7. kees commented on May 12, 2021

    @kees
    kees
    on May 12, 2021

    This is blocked on an LLVM bug: https://llvm.org/pr41459

  8. kees commented on May 12, 2021

    @kees
    kees
    on May 12, 2021

    And blocked on this LLVM bug: https://llvm.org/pr50322

  9. nickdesaulniers commented on Oct 19, 2021

    @nickdesaulniers
    nickdesaulniers
    on Oct 19, 2021
    MemberAuthor

    jotting down notes from trying to run LKDTM:

    / # mount -t sys /sys
/ # mount -t debugfs debugfs /sys/kernel/debug
/ # cat /sys/kernel/debug/provoke-crash/DIRECT
/ # echo FORTIFIED_OBJECT | cat > /sys/kernel/debug/provoke-crash/DIRECT

  10. nathanchance commented on Apr 19, 2022

    @nathanchance
    nathanchance
    on Apr 19, 2022
    Member

    This is fixed with https://git.kernel.org/linus/281d0c962752fb40866dd8d4cade68656f34bd1f.

    #1583 is tracking the !X86_32 in CONFIG_FORTIFY_SOURCE's entry.

  11. nathanchance
    closed this as completedon Apr 19, 2022
  12. nathanchance
    added
    [FIXED][LINUX] 5.18This bug was fixed in Linux 5.18
    and removed
    questionQuestion asked by issue author.
    on Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

[FIXED][LINUX] 5.18This bug was fixed in Linux 5.18securitysecurity implication

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions