Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nickdesaulniers opened this issue Apr 22, 2020 · 8 comments
Closed
Assignees
Labels
[FIXED][LINUX] 5.18 This bug was fixed in Linux 5.18 security security implication

Comments

@nickdesaulniers
Copy link
Member

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.

@nickdesaulniers nickdesaulniers added security security implication question Question asked by issue author. labels Apr 22, 2020
@gburgessiv
Copy link
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. :)

@nathanchance
Copy link
Member

@nathanchance
Copy link
Member

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

@kees
Copy link

kees commented Apr 28, 2021

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

@kees kees self-assigned this Apr 28, 2021
@kees
Copy link

kees commented May 12, 2021

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

@kees
Copy link

kees commented May 12, 2021

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

@nickdesaulniers
Copy link
Member Author

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

@nathanchance
Copy link
Member

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

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

@nathanchance nathanchance added [FIXED][LINUX] 5.18 This bug was fixed in Linux 5.18 and removed question Question asked by issue author. labels Apr 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[FIXED][LINUX] 5.18 This bug was fixed in Linux 5.18 security security implication
Projects
None yet
Development

No branches or pull requests

4 participants