forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 5
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
Improve FORTIFY_SOURCE to detect intra-object overflows #6
Labels
[Feature] FORTIFY_SOURCE
Involves buffer overflow detection
[Linux] v5.11
Released in Linux kernel v5.11
[Linux] v5.18
Released in Linux kernel v5.18
[PATCH] Exists
A patch exists to address the issue
Comments
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Nov 20, 2019
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Jan 17, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]>
Jackeagle
pushed a commit
to Jackeagle/kernel_msm
that referenced
this issue
Jan 17, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a
vineethrp
pushed a commit
to vineethrp/pinephone-linux
that referenced
this issue
Feb 24, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a
Jackeagle
pushed a commit
to Jackeagle/kernel_msm
that referenced
this issue
Feb 24, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: Matthias Maennich <[email protected]>
vineethrp
pushed a commit
to vineethrp/pinephone-linux
that referenced
this issue
Feb 27, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 28, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 28, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 2, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 4, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 5, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
vineethrp
pushed a commit
to vineethrp/pinephone-linux
that referenced
this issue
Mar 6, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 10, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 12, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 13, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Jackeagle
pushed a commit
to Jackeagle/kernel_msm
that referenced
this issue
Mar 14, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: Matthias Maennich <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 16, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Jackeagle
pushed a commit
to Jackeagle/kernel_msm
that referenced
this issue
Mar 21, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: Matthias Maennich <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 23, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
UtsavBalar1231
pushed a commit
to UtsavBalar1231/kernel_xiaomi_raphael
that referenced
this issue
Mar 24, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: UtsavBalar1231 <[email protected]>
UtsavBalar1231
pushed a commit
to UtsavBalar1231/kernel_xiaomi_raphael
that referenced
this issue
Mar 24, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: UtsavBalar1231 <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 24, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 27, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Jackeagle
pushed a commit
to Jackeagle/kernel_msm
that referenced
this issue
Mar 27, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: Matthias Maennich <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 30, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Mar 31, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
Jackeagle
pushed a commit
to Jackeagle/kernel_msm
that referenced
this issue
Mar 31, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Bug: 136249967 Link: https://lore.kernel.org/kernel-hardening/[email protected]/ Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Signed-off-by: Elena Petrova <[email protected]> Change-Id: I1f79faea7386af1bc50faaf8b399ea6448611d5a Signed-off-by: Matthias Maennich <[email protected]>
ruscur
pushed a commit
to ruscur/linux3
that referenced
this issue
Apr 2, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Apr 3, 2020
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Suggested-by: Elena Petrova <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 24, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 24, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 24, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 24, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 24, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 24, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 25, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 25, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 26, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 27, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
Vivekachooz
pushed a commit
to Realme-SM6375-devs/android_kernel_realme_sm6375
that referenced
this issue
Dec 28, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ia122415fd5a55d32677fe177c99aacd725040e50 (cherry picked from commit 277a10850f9f4cb3429faf59293e2c89b1a320be) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 29, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Dec 29, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
Rve27
pushed a commit
to Rv-Project/android_kernel_xiaomi_stone
that referenced
this issue
Dec 29, 2024
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ia122415fd5a55d32677fe177c99aacd725040e50 (cherry picked from commit 277a10850f9f4cb3429faf59293e2c89b1a320be) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]>
Quallenauge
pushed a commit
to Quallenauge/android_kernel_oneplus_sm8350
that referenced
this issue
Jan 6, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 7, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 11, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 11, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 12, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 13, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 16, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
amritokun
pushed a commit
to PaimonLab/kernel_xiaomi_veux
that referenced
this issue
Jan 16, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ia122415fd5a55d32677fe177c99aacd725040e50 (cherry picked from commit 277a10850f9f4cb3429faf59293e2c89b1a320be) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 28, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Jan 31, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
Karan-Frost
pushed a commit
to frost-testzone/kernel_xiaomi_sm6375
that referenced
this issue
Feb 7, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ia122415fd5a55d32677fe177c99aacd725040e50 (cherry picked from commit 277a10850f9f4cb3429faf59293e2c89b1a320be) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Feb 9, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Feb 10, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
amritokun
pushed a commit
to PaimonLab/kernel_xiaomi_veux
that referenced
this issue
Feb 11, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ia122415fd5a55d32677fe177c99aacd725040e50 (cherry picked from commit 277a10850f9f4cb3429faf59293e2c89b1a320be) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]>
amritokun
pushed a commit
to PaimonLab/kernel_xiaomi_veux
that referenced
this issue
Feb 11, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ia122415fd5a55d32677fe177c99aacd725040e50 (cherry picked from commit 277a10850f9f4cb3429faf59293e2c89b1a320be) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]>
TogoFire
pushed a commit
to dev-sm8350/kernel_oneplus_sm8350
that referenced
this issue
Feb 19, 2025
In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] KSPP/linux#6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova <[email protected]> Signed-off-by: Kees Cook <[email protected]> Change-Id: I5939f3de9bf404ba86ab258c1e8b47153f1b531c Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Ryabinin <[email protected]> Acked-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: "Gustavo A. R. Silva" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 277a108) [lenaptr: Resolved minor conflicts in lib/Kconfig.ubsan and scripts/Makefile.ubsan] Signed-off-by: Elena Petrova <[email protected]> [dereference23: Fixed incorrect conflict resolution] Signed-off-by: Alexander Winkowski <[email protected]> (cherry picked from commit a35b59ea4015de420bc51f605c741e4084f90819) Signed-off-by: TogoFire <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
[Feature] FORTIFY_SOURCE
Involves buffer overflow detection
[Linux] v5.11
Released in Linux kernel v5.11
[Linux] v5.18
Released in Linux kernel v5.18
[PATCH] Exists
A patch exists to address the issue
Right now,
CONFIG_FORTIFY_SOURCE
uses__builtin_object_size(member, 0)
, which returns the size of the larger structure (inter-object bounds checking). In the case of:CONFIG_FORTIFY_SOURCE
will check that the write does not go past the end ofinstance
, but it will allow an overflow beyond the end offirst
intomiddle
andfinal
.Fixing this will likely require several steps:
__builtin_object_size(member, 1)
to gain intra-object bounds checking forstr*()
family functions. A patch for this already exists. Landed in commit 6a39e62 (v5.11)__builtin_object_size(member, 1)
formem*()
family functions, there are several cases in the kernel where copies are intentionally targeting the address of a structure member but intentionally write across multiple structure members. For example, with the above structurememcpy(&instance->middle, src, sizeof(int) * 2)
. So many patches landed for these fixes.mem*()
family functions. Landed in commit f68f2ff (v5.18)mem*()
family functions.mem*()
family functions.The text was updated successfully, but these errors were encountered: