add the option of fortified string.h functions
Subsystems (5)
PATCH v3 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 like strlcat.
* 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 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 v2:
- add fortified strlcpy
- split the compile-time errors for reads and writes, and specify the parameter
- avoid redefinition of __NO_FORTIFY in KASan-uninstrumented code already defining __NO_FORTIFY
arch/arm64/include/asm/string.h | 5 + arch/x86/boot/compressed/misc.c | 5 + arch/x86/include/asm/string_64.h | 5 + include/linux/string.h | 200 +++++++++++++++++++++++++++++++++++++++ lib/string.c | 6 ++ security/Kconfig | 6 ++ 6 files changed, 227 insertions(+)
arch/arm64/include/asm/string.h +5 -0
@@ -63,6 +63,11 @@ 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) + +#ifndef __NO_FORTIFY +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif +#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 +5 -0
@@ -77,6 +77,11 @@ 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) + +#ifndef __NO_FORTIFY +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif +#endif #define __HAVE_ARCH_MEMCPY_MCSAFE 1
include/linux/string.h +200 -0
204 lines not on this page · raw message
lib/string.c +6 -0
@@ -978,3 +978,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.13.0
Quoted 31 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.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 like strlcat.
* 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.
Quoted 5 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.
Signed-off-by Daniel Micay <[email protected]>
This is great to have. While it was out-of-tree code, it would have blocked at least CVE-2016-3858 from being exploitable (improper size argument to strlcpy()). I've sent a number of fixes for out-of-bounds-reads that this detected upstream already. If I can collect Acks on this, I could carry it in the kspp tree for -next along with any other fixes. Otherwise, perhaps it can go via -mm?
Thanks!
-Kees
Quoted 302 lines
---
Changes since v2:
- add fortified strlcpy
- split the compile-time errors for reads and writes, and specify the parameter
- avoid redefinition of__NO_FORTIFYin KASan-uninstrumented code already defining__NO_FORTIFYarch/arm64/include/asm/string.h | 5 + arch/x86/boot/compressed/misc.c | 5 + arch/x86/include/asm/string_64.h | 5 + include/linux/string.h | 200 +++++++++++++++++++++++++++++++++++++++ lib/string.c | 6 ++ security/Kconfig | 6 ++ 6 files changed, 227 insertions(+)arch/arm64/include/asm/string.h +5
-0@@ -63,6 +63,11 @@ 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) + +#ifndef __NO_FORTIFY +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif +#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 +5
-0@@ -77,6 +77,11 @@ 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) + +#ifndef __NO_FORTIFY +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif +#endif #define __HAVE_ARCH_MEMCPY_MCSAFE 1include/linux/string.h +200
-0@@ -187,4 +187,204 @@ static inline const char *kbasename(const char *path)return tail ? tail +1 : path; } +#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline)) +#define __RENAME (x) __asm__(#x) + +void fortify_panic (const char *name)__noreturn __cold ; +void __read_overflow(void) __compiletime_error("detected read beyond size of object passed as 1st parameter"); +void __read_overflow2(void) __compiletime_error("detected read beyond size of object passed as 2nd parameter"); +void __write_overflow(void) __compiletime_error("detected write beyond size of object passed as 1st parameter"); + +#if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE ) +__FORTIFY_INLINE char *strcpy(char *p, const char *q) +{ +size_t p_size =__builtin_object_size (p,0 ); +size_t q_size =__builtin_object_size (q,0 ); +if (p_size == (size_t )-1 && q_size == (size_t )-1 ) +return __builtin_strcpy (p, q); +if (strscpy (p, q, p_size < q_size ? p_size : q_size) <0 ) +fortify_panic (__func__); +return p; +} + +__FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (__builtin_constant_p (size) && p_size < size) +__write_overflow (); +if (p_size < size) +fortify_panic (__func__); +return __builtin_strncpy (p, q, size); +} + +__FORTIFY_INLINE char *strcat(char *p, const char *q) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (p_size == (size_t )-1 ) +return __builtin_strcat (p, q); +if (strlcat (p, q, p_size) >= p_size) +fortify_panic (__func__); +return p; +} + +__FORTIFY_INLINE __kernel_size_t strlen(const char *p) +{ +__kernel_size_t ret; +size_t p_size =__builtin_object_size (p,0 ); +if (p_size == (size_t )-1 ) +return __builtin_strlen (p); + ret =strnlen (p, p_size); +if (p_size <= ret) +fortify_panic (__func__); +return ret; +} + +extern __kernel_size_t __real_strnlen(const char *, __kernel_size_t) __RENAME(strnlen); +__FORTIFY_INLINE __kernel_size_t strnlen(const char *p, __kernel_size_t maxlen) +{ +size_t p_size =__builtin_object_size (p,0 ); +__kernel_size_t ret =__real_strnlen (p, maxlen < p_size ? maxlen : p_size); +if (p_size <= ret) +fortify_panic (__func__); +return ret; +} + +/* defined after fortified strlen to reuse it */ +extern size_t __real_strlcpy(char *, const char *, size_t) __RENAME(strlcpy); +__FORTIFY_INLINE size_t strlcpy(char *p, const char *q, size_t size) +{ +size_t ret; +size_t p_size =__builtin_object_size (p,0 ); +size_t q_size =__builtin_object_size (q,0 ); +if (p_size == (size_t )-1 && q_size == (size_t )-1 ) +return __real_strlcpy (p, q, size); + ret =strlen (q); +if (size) { +size_t len = (ret >= size) ? size -1 : ret; +if (__builtin_constant_p (len) && len >= p_size) +__write_overflow (); +if (len >= p_size) +fortify_panic (__func__); +__builtin_memcpy (p, q, len); + p[len] ='\0' ; + } +return ret; +} + +/* defined after fortified strlen and strnlen to reuse them */ +__FORTIFY_INLINE char *strncat(char *p, const char *q, __kernel_size_t count) +{ +size_t p_len, copy_len; +size_t p_size =__builtin_object_size (p,0 ); +size_t q_size =__builtin_object_size (q,0 ); +if (p_size == (size_t )-1 && q_size == (size_t )-1 ) +return __builtin_strncat (p, q, count); + p_len =strlen (p); + copy_len =strnlen (q, count); +if (p_size < p_len + copy_len +1 ) +fortify_panic (__func__); +__builtin_memcpy (p + p_len, q, copy_len); + p[p_len + copy_len] ='\0' ; +return p; +} + +__FORTIFY_INLINE void *memset(void *p, int c, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (__builtin_constant_p (size) && p_size < size) +__write_overflow (); +if (p_size < size) +fortify_panic (__func__); +return __builtin_memset (p, c, size); +} + +__FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +size_t q_size =__builtin_object_size (q,0 ); +if (__builtin_constant_p (size)) { +if (p_size < size) +__write_overflow (); +if (q_size < size) +__read_overflow2 (); + } +if (p_size < size || q_size < size) +fortify_panic (__func__); +return __builtin_memcpy (p, q, size); +} + +__FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +size_t q_size =__builtin_object_size (q,0 ); +if (__builtin_constant_p (size)) { +if (p_size < size) +__write_overflow (); +if (q_size < size) +__read_overflow2 (); + } +if (p_size < size || q_size < size) +fortify_panic (__func__); +return __builtin_memmove (p, q, size); +} + +extern void *__real_memscan (void *,int ,__kernel_size_t )__RENAME (memscan); +__FORTIFY_INLINE void *memscan(void *p, int c, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (__builtin_constant_p (size) && p_size < size) +__read_overflow (); +if (p_size < size) +fortify_panic (__func__); +return __real_memscan (p, c, size); +} + +__FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +size_t q_size =__builtin_object_size (q,0 ); +if (__builtin_constant_p (size)) { +if (p_size < size) +__read_overflow (); +if (q_size < size) +__read_overflow2 (); + } +if (p_size < size || q_size < size) +fortify_panic (__func__); +return __builtin_memcmp (p, q, size); +} + +__FORTIFY_INLINE void *memchr(const void *p, int c, __kernel_size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (__builtin_constant_p (size) && p_size < size) +__read_overflow (); +if (p_size < size) +fortify_panic (__func__); +return __builtin_memchr (p, c, size); +} + +void *__real_memchr_inv (const void *s,int c,size_t n)__RENAME (memchr_inv); +__FORTIFY_INLINE void *memchr_inv(const void *p, int c, size_t size) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (__builtin_constant_p (size) && p_size < size) +__read_overflow (); +if (p_size < size) +fortify_panic (__func__); +return __real_memchr_inv (p, c, size); +} + +extern void *__real_kmemdup (const void *src,size_t len,gfp_t gfp)__RENAME (kmemdup); +__FORTIFY_INLINE void *kmemdup(const void *p, size_t size, gfp_t gfp) +{ +size_t p_size =__builtin_object_size (p,0 ); +if (__builtin_constant_p (size) && p_size < size) +__read_overflow (); +if (p_size < size) +fortify_panic (__func__); +return __real_kmemdup (p, size, gfp); +} +#endif +#endif /* _LINUX_STRING_H_ */ lib/string.c +6
-0@@ -978,3 +978,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
-1@@ -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 --2.13.0
Signature · 2 lines
Kees Cook Pixel Security
Andrew Morton
maintainerQuoted 26 lines · On Mon, 22 May 2017 19:10:25 -0400 Daniel Micay <[email protected]> wrote:
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.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 like strlcat.
Quoted 8 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 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.
Confused by the final paragraph. The patch adds CONFIG_FORTIFY_SOURCE so isn't that to-do item completed?
Also, what does __NO_FORTIFY do? Nothing ever defines it?
Quoted 33 lines · Andrew Morton
Quoted 31 lines · On Mon, 22 May 2017 19:10:25 -0400 Daniel Micay <[email protected]> wrote:
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.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 like strlcat.
* 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.
Quoted 6 lines
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.
Confused by the final paragraph. The patch adds
CONFIG_FORTIFY_SOURCEso isn't that to-do item completed?
Right now FORTIFY_SOURCE performs two checks: compile-time (when both sizes can be determined) and run-time (when only destination size can be determined). They could be split, if it ever makes sense to do so. For example, the compile-time checks could be made mandatory once all fixes everywhere else have stabilized, and split the run-time checks as a new CONFIG (since they technically do add a small bump to .text size). I think maybe the best option for the future would be to just make the compile-time checks mandatory and have CONFIG_FORTIFY_SOURCE just cover the runtime checks. But let's see how far we get as-is.
Quoted 1 line
Also, what does
__NO_FORTIFYdo? Nothing ever defines it?
It's used to disable FORTIFY coverage as needed in the build. It's used in this patch already to avoid collision with KASan.
I've been sending fixes for things that FORTIFY detected, and most have been taken by various maintainers. Do you want to carry the remaining fixes I have in my kssp/fortify tree, or should I keep pestering maintainers? I can recheck -next to see which are outstanding and send them to you...
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 64 lines · Kees Cook
Quoted 58 lines · Andrew Morton
Quoted 49 lines · On Mon, 22 May 2017 19:10:25 -0400 Daniel Micay <[email protected] om> wrote:
This adds support for compiling with a rough equivalent to the glibc
_FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
overflow checks forstring.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.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 like strlcat.
* 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.Quoted 5 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.Quoted 3 lines
Confused by the final paragraph. The patch adds
CONFIG_FORTIFY_SOURCE
so isn't that to-do item completed?
Quoted 9 lines
Right now
FORTIFY_SOURCEperforms two checks: compile-time (when both sizes can be determined) and run-time (when only destination size can be determined). They could be split, if it ever makes sense to do so. For example, the compile-time checks could be made mandatory once all fixes everywhere else have stabilized, and split the run-time checks as a new CONFIG (since they technically do add a small bump to .text size). I think maybe the best option for the future would be to just make the compile-time checks mandatory and haveCONFIG_FORTIFY_SOURCEjust cover the runtime checks. But let's see how far we get as-is.
It'll add a bit of complexity and we'll need to make sure to avoid causing any performance hit for the compile-time-only mode.
The compile-time checks might also be incredibly annoying with Clang. I think it might currently ignore the error attribute, so instead of an error comprehensible to a human it will instead cause a linker error later on with no context tied to the source code. The runtime checks should work fine with Clang already unlike the approach in glibc.
Quoted 4 lines
Quoted 1 line
Also, what does
__NO_FORTIFYdo? Nothing ever defines it?It's used to disable FORTIFY coverage as needed in the build. It's used in this patch already to avoid collision with KASan.
KASan instruments the memcpy, memmove and memset symbols to perform the sanitizer checking for them.
It needs to bypass that when instrumentation is supposed to be disabled so the kernel uses a hack where it #defines memcpy as __memcpy, which bypasses the instrumented KASan functions. So __NO_FORTIFY gets used there to avoid the KASan hack from causing strange interactions with the fortify code. It ends up turning the fortified memcpy into fortified __memcpy with that define and makes it call memcpy via __builtin_memcpy resulting in KASan false positives by instrumenting calls that it is trying to leave uninstrumented.
Someone might be able to come up with a better solution like using the same __RENAME trick for KASan instead of that #define hack, but it only turns of fortify coverage for a *tiny* amount of code and only in KASan builds, so I don't think it's worth worrying too much about.
Quoted 5 lines
I've been sending fixes for things that FORTIFY detected, and most have been taken by various maintainers. Do you want to carry the remaining fixes I have in my kssp/fortify tree, or should I keep pestering maintainers? I can recheck -next to see which are outstanding and send them to you...
1. It's also only the start of it since it's primarily the ones with compile-time read/write sizes which are probably all fixed now other than some architecture-specific ones. The runtime checks extend the coverage a lot, and it'll grow some more with alloc_size markers and some other changes.
Andrew Morton
maintainerQuoted 5 lines · On Mon, 22 May 2017 19:10:25 -0400 Daniel Micay <[email protected]> wrote:
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.
i386 allmodconfig, gcc-6.3.0:
In file included from ./arch/x86/include/asm/string.h:2:0,
from ./include/linux/string.h:18,
from ./arch/x86/include/asm/page_32.h:34,
from ./arch/x86/include/asm/page.h:13,
from ./arch/x86/include/asm/thread_info.h:11,
from ./include/linux/thread_info.h:37,
from ./arch/x86/include/asm/preempt.h:6,
from ./include/linux/preempt.h:80,
from ./include/linux/spinlock.h:50,
from ./include/linux/seqlock.h:35,
from ./include/linux/time.h:5,
from ./include/linux/stat.h:18,
from ./include/linux/module.h:10,
from drivers/acpi/ac.c:23:
./include/linux/string.h: In function 'acpi_ac_add':
./arch/x86/include/asm/string_32.h:182:25: error: inlining failed in call to always_inline '__builtin_memcpy': function body not available
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
./include/linux/string.h:301:24: note: in expansion of macro 'memcpy'
__FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
^~~~~~
In file included from ./arch/x86/include/asm/page_32.h:34:0,
from ./arch/x86/include/asm/page.h:13,
from ./arch/x86/include/asm/thread_info.h:11,
from ./include/linux/thread_info.h:37,
from ./arch/x86/include/asm/preempt.h:6,
from ./include/linux/preempt.h:80,
from ./include/linux/spinlock.h:50,
from ./include/linux/seqlock.h:35,
from ./include/linux/time.h:5,
from ./include/linux/stat.h:18,
from ./include/linux/module.h:10,
from drivers/acpi/ac.c:23:
./include/linux/string.h:204:10: note: called from here
return __builtin_strcpy(p, q);
^~~~~~~~~~~~~~~~~~~~~~
In file included from ./arch/x86/include/asm/string.h:2:0,
from ./include/linux/string.h:18,
from ./arch/x86/include/asm/page_32.h:34,
from ./arch/x86/include/asm/page.h:13,
from ./arch/x86/include/asm/thread_info.h:11,
from ./include/linux/thread_info.h:37,
from ./arch/x86/include/asm/preempt.h:6,
from ./include/linux/preempt.h:80,
from ./include/linux/spinlock.h:50,
from ./include/linux/seqlock.h:35,
from ./include/linux/time.h:5,
from ./include/linux/stat.h:18,
from ./include/linux/module.h:10,
from drivers/acpi/ac.c:23:
./arch/x86/include/asm/string_32.h:182:25: error: inlining failed in call to always_inline '__builtin_memcpy': function body not available
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
./include/linux/string.h:301:24: note: in expansion of macro 'memcpy'
__FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
^~~~~~
In file included from ./arch/x86/include/asm/page_32.h:34:0,
from ./arch/x86/include/asm/page.h:13,
from ./arch/x86/include/asm/thread_info.h:11,
from ./include/linux/thread_info.h:37,
from ./arch/x86/include/asm/preempt.h:6,
from ./include/linux/preempt.h:80,
from ./include/linux/spinlock.h:50,
from ./include/linux/seqlock.h:35,
from ./include/linux/time.h:5,
from ./include/linux/stat.h:18,
from ./include/linux/module.h:10,
from drivers/acpi/ac.c:23:
./include/linux/string.h:204:10: note: called from here
return __builtin_strcpy(p, q);
^~~~~~~~~~~~~~~~~~~~~~make[1]: *** [drivers/acpi/ac.o] Error 1
make: *** [drivers/acpi/ac.o] Error 2
Quoted 6 lines · Daniel Micay
arch/x86/include/asm/string_64.h +0
-0@@ -77,6 +77,11 @@ int strcmp(const char *cs, const char *ct);#define memcpy (dst, src, len) __memcpy(dst, src, len)
arch/x86/include/asm/string_64.h int strcmp(const char *cs, const char *ct); · line 87
Quoted 10 lines
arch/x86/include/asm/string_64.h +5
-0#define memmove (dst, src, len) __memmove(dst, src, len)#define memset (s, c, n) __memset(s, c, n) + +#ifndef __NO_FORTIFY +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif +#endif #define __HAVE_ARCH_MEMCPY_MCSAFE 1
Ah-ha, this same KASAN exclusion is missing for string_32.h, which is what I think akpm tripped over in build tests.
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 19 lines · Kees Cook
Quoted 17 lines · Daniel Micay
arch/x86/include/asm/string_64.h +5
-0@@ -77,6 +77,11 @@ 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) + +#ifndef __NO_FORTIFY +#define __NO_FORTIFY/* FORTIFY_SOURCE uses __builtin_memcpy, etc. */ +#endif +#endif
Quoted 6 lines
Quoted 1 line
#define
__HAVE_ARCH_MEMCPY_MCSAFE1Ah-ha, this same KASAN exclusion is missing for
string_32.h, which is what I think akpm tripped over in build tests.-Kees
It's not KASAN-related but rather some cruft that's still around in the 32-bit x86 header. It unnecessarily defines memcpy as __builtin_memcpy even though the built-in is already used on modern GCC, while the 64-bit header only does a similar define for GCC < 4.3. I'll just make it stop doing that with fortify enabled.