Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Kernel Self-Protection Project and how you ...

The Kernel Self-Protection Project and how you can help

This presentation will cover some of the most recent KSPP accomplishments, as well as some currently active efforts. Also, a brief explanation of how you can help us complete some particularly challenging work will be presented.

Gustavo A. R. Silva

Kernel Recipes

June 09, 2024
Tweet

More Decks by Kernel Recipes

Other Decks in Technology

Transcript

  1. 1 The Kernel Self-Protection Project and how you can help

    Gustavo A. R. Silva [email protected] @embeddedgus Supported by The Linux Foundation & Google Kernel Recipes June 2, 2022 Paris, France
  2. Who am I? • Embedded Systems. • RTOS & Embedded

    Linux. • Upstream first – 6 years. • Kernel developer & maintainer. • GOSST - Linux kernel division. • Volunteer at @kidsoncomputers
  3. Who am I? • Embedded Systems. • RTOS & Embedded

    Linux. • Upstream first – 6 years. • Kernel developer & maintainer. • GOSST - Linux kernel division. • Volunteer at @kidsoncomputers “Tuxote”
  4. Agenda • The Kernel Self-Protection Project • Work in progress

    and some accomplishments. • How you can help. :) • Conclusions.
  5. The Kernel Self-Protection Project • It’s an upstream project. Not

    a random downstream clone of Linux. • Focused on hardening the upstream Linux kernel. • We want to eliminate entire bug classes and methods of exploitation. • Developing of defense mechanisms that cut off whole classes of vulnerabilities. Best way to approach the problem of security. • Moving the codebase to use safer APIs. • Not about writing CVEs.
  6. linux-hardening • Upstream mailing list. Created in 2020. • Needed

    a list to discuss development, maintenance and all things related. • Old list (kernel-hardening) only wanted new stuff. • A place to discuss about all the small details and middle steps in the process of hardening the kernel was needed. • [email protected] • https://lore.kernel.org/linux-hardening/202009281907.946FBE7B@keescook/
  7. Patchwork • Keep track of tags: Reviewed-by, Tested-by, Acked-by, etc.

    • The KSPP is not a subsystem, but it has maintainers. :P • Sometimes work gets stuck and patches are not applied -for a number of reasons. • Patches are sometimes ignored. • Don’t want to miss patches from occasional contributors. • Helpful to follow up on all patches sent to the linux-hardening list, so we can carry them on our -next trees when needed. • https://patchwork.kernel.org/project/linux-hardening/
  8. Issue tracker • Issues show up while addressing other… issues.

    • Sound familiar? :) • Sometimes we need to document stuff before it’s included in the official documentation. • We have good first issues. :) • https://github.com/KSPP/linux/issues
  9. • "There is never too much information you can put

    in a merge commit. Put what you ate on breakfast. Put everything in there." – David Miller. #netconf2019
  10. • Linus doesn’t care what you had for breakfast. :/

    • But Dave does. Thanks Dave. :)
  11. Coverity • Not actually for kernel hardening, but it’s a

    good tool for new people. • Public. • Should be named linux-next-daily-scan. • Daily scans for linux-next. • Kees runs daily builds on his beefy machine. • Good place to start for newcomers. Send a request for access. :) • https://scan.coverity.com/projects/linux-next-weekly-scan/
  12. Coccinelle • We use it frequently. • Not a magical

    solution for all we need to fix or change. • Code still should be audited. :) • https://coccinelle.gitlabpages.inria.fr/website/
  13. Kernel Test Robot • Build-tests for multiple archs and configurations.

    GCC and Clang. • Results usually within 24 hours. • Need to ask for your tree to be added to their test suite. • Private and public reports. Depending on your preferences. • Our test reports are publicly available on LKML. • For complex changes I usually include a Build-tested-by tag with a link to the results. • Kernel Test Robot <[email protected]>
  14. IRC channels and wiki • Wanna hang out? :) •

    #linux-hardening • #clangbuiltlinux • Libera.Chat • https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
  15. What does it take to harden the kernel? • KSPP

    is about hardening the Linux kernel. • The goals are big. • It’s usually not as glamorous as people would think. • Auditing code is exhausting and time consuming. • We need to develop some strategies. • Make the compiler an ally.
  16. What does it take to harden the kernel? • Enabling

    compiler options is an important step forward. • Provide the compiler with enough context. • Detect as many problems as possible at build-time. • Enabling compiler options is not that straightforward. • Upstream has its implications. Who would’ve thought? :p • Need to solve both technical and political problems.
  17. What does it take to harden the kernel? • Political

    issues tend to delay the work. • Some people really dislike some changes. • We need to convince people. • People have different opinions about security changes across the whole kernel tree. • Fortunately, some people really support the project.
  18. What does it take to harden the kernel? • A

    lot of middle steps need to land in order to complete important work. • Clean ups and mechanical changes. • Some are easy to implement, but hard to have them applied upstream. • Maintainers usually don’t like a mechanical change happen external to their tree. • Avoid friction.
  19. Enabling compiler options • Why is it a complex task?

    • Usually tons of warnings. :) • “The noisy thing.” • Some actual bugs, some false positives. • Both are worth resolving. • Some of those warnings lead us to find corner cases in both kernel code and the compiler.
  20. Enabling compiler options • Maybe we need to change the

    narrative a little bit. • Small (although not simple) task are usually seen as noisy and code churn. • Accomplishing important things require to pay attention to small details, first. • The 99-1 rule. 99% perspiration/frustration, 1% inspiration/innovation. • Improving the quality and maintainability of the code allows for trying to implement more complex stuff.
  21. Work in progress and some accomplishments • struct_group() • Flexible

    array transformations. • -Warray-bounds • memcpy() hardening and the compound effect.
  22. struct_group() • Wrap a set of declarations in a mirrored

    struct. • Group adjacent members in a struct to be accessed together. Usually through memcpy() or memset(). • Update to FORTIFY_SOURCE caused some memcpy() and memset() warnings when accessing multiple adjacent members of a structure at once. • The flexibility of the C language. ;)
  23. FORTIFY_SOURCE • Uses the compiler's __builtin_object_size(). • Determine the available

    size at a target address based on the compile-time known structure layout details. • Operates in two modes: – Outer bounds: __builtin_object_size(object, 0) – Inner bounds: __builtin_object_size(object, 1) • More details: commit f68f2ff91512
  24. Flexible array transformations • 0-element was a GNU extension. 1-element

    was a hack. • Flexible array member was introduced in C99. • One-element arrays are particularly confusing and prone to error. • zero-element and one-element arrays are deprecated. https://www.kernel.org/doc/html/latest/process/deprecated.html #zero-length-and-one-element-arrays • These transformations are tricky and not that straightforward. I have introduced bugs (all fixed already :p) while doing flexible array transformations.
  25. one-element array • We have to remember to calculate n

    - 1 when using the struct_size() helper.
  26. flexible array member • Now, with the hardened memcpy(), we

    can omit the use of flex_array_size() in this case.
  27. Flexible arrays and trailing arrays • Compilers treat all trailing

    arrays as flexible arrays. • It breaks FORTIFY_SOURCE in that any struct with a fixed size trailing array will receive no sanity checking. • It seems that there are a lot of legacy code “taking advantage” of that. • -fstrict-flex-array? • GCC and Clang bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419 https://github.com/llvm/llvm-project/issues/55741
  28. -Warray-bounds • Enabled for GCC 11 and earlier. :) •

    153 more new warnings with GCC 12 • v5.18, GCC 11 to GCC 12: $ grep warning: fedora36.log | grep 'Warray-bounds' | wc -l 153 • https://github.com/KSPP/linux/issues/190
  29. Other work • -Wstringop-overflow making progress. https://git.kernel.org/linus/a3a8b54b4f1a • -Wimplicit-fallhrough for

    Clang is now enabled. We had almost 40,000 warnings. https://github.com/KSPP/linux/issues/115 • -Wcast-function-type is now enabled. https://git.kernel.org/linus/01367e86e90
  30. How you can help. :) • Doing flexible array transformations,

    of course. :) https://github.com/KSPP/linux/issues/79 • Issue 79 contains a list with hundreds of patches that have landed in mainline. They can be used as examples. • Audit code and use the helpers available, when possible: struct_size(), struct_group(), flex_array_size(), size_add(), size_mul(), etc. See commit e1be43d9b5d0 • Take a look at the issue tracker. We have issues for everybody. :) https://github.com/KSPP/linux/issues/
  31. one-element arrays to flexible arrays • Find uses of sizeof

    on the involved struct-with-one-element- array or on the type of the one-element array itself. • Find the n – 1 pattern and change it to just n. If you don’t find this pattern then something else may be going on, and you need to carefully verify that the size for the allocation and the iteration over the array are correct. Otherwise, chances are you just found a bug (usually an off-by-one error). • Look for any iteration over the array and verify it is still within the boundaries. Usually in the form of a for loop. Use diffoscope before/after the changes to check the binary. • CC-me: [email protected]
  32. The best outcome • In regards to the technical portion

    of this work, we want to achieve having a robust and hardened kernel with secure core infrastructure and safer APIs, that allow us to both eliminate entire bug classes and methods of exploitation in the upstream Linux kernel. That definitely would be the best outcome.
  33. Political work • Hopefully the social and political work we've

    been doing all this time will make it easier to introduce more changes that improve the security of the kernel and, at the same time, benefit new people that want to collaborate with us by helping them navigate with ease the, sometimes, wild waters of the Linux kernel community.
  34. A commit at a time • Change in the kernel,

    especially in terms of security, is an evolutionary process. It is slow and demands a lot of patience. There is still more work than we can get done. We always welcome people who can help out. Companies participating in any ecosystem that's based on Linux need to really consider funding projects that improve the overall security of the kernel. This is an effort that is driving change a commit at a time and, that benefits billions of people around the world, including of course, users and customers of tech companies of all sizes. https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html