add the option of fortified string.h functions
Subsystems (5)
PATCH v2 1/1 add the option of fortified string.h functions
This adds support for compiling with a rough equivalent to the glibc _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer overflow checks for string.h functions when the compiler determines the size of the source or destination buffer at compile-time. Unlike glibc, it covers buffer reads in addition to writes.
GNU C __builtin_*_chk intrinsics are avoided because they would force a much more complex implementation. They aren't designed to detect read overflows and offer no real benefit when using an implementation based on inline checks. Inline checks don't add up to much code size and allow full use of the regular string intrinsics while avoiding the need for a bunch of _chk functions and per-arch assembly to avoid wrapper overhead.
This detects various overflows at compile-time in various drivers and some non-x86 core kernel code. There will likely be issues caught in regular use at runtime too.
Future improvements left out of initial implementation for simplicity, as it's all quite optional and can be done incrementally:
* Some of the fortified string functions (strncpy, strcat), don't yet place a limit on reads from the source based on __builtin_object_size of the source buffer.
* Extending coverage to more string functions (strlcpy, strlcat) and perhaps making the memory buffer checks into something more reusable for broader use.
* It should be possible to optionally use __builtin_object_size(x, 1) for some functions (C strings) to detect intra-object overflows (like glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative approach to avoid likely compatibility issues.
* The error reporting could be made friendlier by splitting up the compile-time error for reads and writes.
* The compile-time checks should be made available via a separate config option which can be enabled by default (or always enabled) once enough time has passed to get the issues it catches fixed.
---
Changes since v1:
* fix compatibility with CONFIG_KASAN
* replace strlcpy with strscpy in fortified strcpy and verify the source buffer
* use fortified strlen/strnlen in fortified strncat to check for read overflow
arch/arm64/include/asm/string.h | 3 + arch/x86/boot/compressed/misc.c | 5 ++ arch/x86/include/asm/string_64.h | 3 + include/linux/string.h | 164 +++++++++++++++++++++++++++++++++++++++ lib/string.c | 6 ++ security/Kconfig | 6 ++ 6 files changed, 187 insertions(+)
arch/arm64/include/asm/string.h +3 -0
@@ -63,6 +63,9 @@ extern int memcmp(const void *, const void *, size_t);#define memcpy (dst, src, len) __memcpy(dst, src, len)#define memmove (dst, src, len) __memmove(dst, src, len)#define memset (s, c, n) __memset(s, c, n) + +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif #endif
arch/x86/boot/compressed/misc.c +5 -0
@@ -409,3 +409,8 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,debug_putstr ("done.\nBooting the kernel.\n" );return output; } + +void fortify_panic (const char *name) +{ +error ("detected buffer overflow" ); +}
arch/x86/include/asm/string_64.h +3 -0
@@ -77,6 +77,9 @@ int strcmp(const char *cs, const char *ct);#define memcpy (dst, src, len) __memcpy(dst, src, len)#define memmove (dst, src, len) __memmove(dst, src, len)#define memset (s, c, n) __memset(s, c, n) + +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif __must_check int memcpy_mcsafe_unrolled (void *dst,const void *src,size_t cnt);
include/linux/string.h +164 -0
168 lines not on this page · raw message
lib/string.c +6 -0
@@ -952,3 +952,9 @@ char *strreplace(char *s, char old, char new)return s; }EXPORT_SYMBOL (strreplace); + +void fortify_panic (const char *name) +{ +panic ("detected buffer overflow in %s" , name); +} +EXPORT_SYMBOL (fortify_panic);
security/Kconfig +6 -0
@@ -154,6 +154,12 @@ config HARDENED_USERCOPY_PAGESPAN been removed. This config is intended to be used only while trying to find such users. +config FORTIFY_SOURCE + bool "Harden common functions against buffer overflows" + help + Detect overflows of buffers in common functions where the compiler + can determine the buffer size. + config STATIC_USERMODEHELPER bool "Force all usermode helper calls through a single binary" help
Signature · 1 line
2.12.2
Quoted 5 lines · Daniel Micay
This adds support for compiling with a rough equivalent to the glibc _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer overflow checks for
string.hfunctions when the compiler determines the size of the source or destination buffer at compile-time. Unlike glibc, it covers buffer reads in addition to writes.
For folks doing testing of this, I've put a tree up here:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/fortify
This includes stuff I've seen fixes for (including the two from Mark Rutland).
Quoted 22 lines
GNU C __builtin_*_chk intrinsics are avoided because they would force a much more complex implementation. They aren't designed to detect read overflows and offer no real benefit when using an implementation based on inline checks. Inline checks don't add up to much code size and allow full use of the regular string intrinsics while avoiding the need for a bunch of
_chkfunctions and per-arch assembly to avoid wrapper overhead.This detects various overflows at compile-time in various drivers and some non-x86 core kernel code. There will likely be issues caught in regular use at runtime too.
Future improvements left out of initial implementation for simplicity, as it's all quite optional and can be done incrementally:
* Some of the fortified string functions (strncpy, strcat), don't yet place a limit on reads from the source based on
__builtin_object_sizeof the source buffer.* Extending coverage to more string functions (strlcpy, strlcat) and perhaps making the memory buffer checks into something more reusable for broader use.
Quoted 7 lines
* It should be possible to optionally use
__builtin_object_size(x, 1)for some functions (C strings) to detect intra-object overflows (like glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative approach to avoid likely compatibility issues.* The error reporting could be made friendlier by splitting up the compile-time error for reads and writes.
I've implemented this in my tree.
Quoted 3 lines
* The compile-time checks should be made available via a separate config option which can be enabled by default (or always enabled) once enough time has passed to get the issues it catches fixed.
Yeah, this would be nice to avoid entirely disabling it for things like EFI stub, etc.
I suspect there will be a v3, but since this already works very nicely for me:
Thanks!
-Kees
Signature · 2 lines
Kees Cook Pixel Security