add the option of fortified string.h functions
Subsystems (8)
PATCH v4 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 v3:
- Worked around conflicts with x86 string function defines, which were mostly legacy optimizations not relevant to current GCC. At some point these headers could be stripped down to drop all these hacks not needed with GCC from the past 6+ years.
arch/arm64/include/asm/string.h | 5 + arch/x86/boot/compressed/misc.c | 5 + arch/x86/include/asm/string_32.h | 9 ++ arch/x86/include/asm/string_64.h | 7 ++ include/linux/string.h | 200 +++++++++++++++++++++++++++++++++++++++ lib/string.c | 6 ++ security/Kconfig | 6 ++ 7 files changed, 238 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_32.h +9 -0
@@ -142,7 +142,9 @@ static __always_inline void *__constant_memcpy(void *to, const void *from, }#define __HAVE_ARCH_MEMCPY +extern void *memcpy (void *,const void *,size_t ); +#ifndef CONFIG_FORTIFY_SOURCE #ifdef CONFIG_X86_USE_3DNOW #include <asm/mmx.h>
@@ -195,11 +197,15 @@ static inline void *__memcpy3d(void *to, const void *from, size_t len)#endif #endif +#endif /* !CONFIG_FORTIFY_SOURCE */ #define __HAVE_ARCH_MEMMOVEvoid *memmove (void *dest,const void *src,size_t n); +extern int memcmp (const void *,const void *,size_t ); +#ifndef CONFIG_FORTIFY_SOURCE #define memcmp __builtin_memcmp +#endif #define __HAVE_ARCH_MEMCHRextern void *memchr (const void *cs,int c,size_t count);
@@ -321,6 +327,8 @@ void *__constant_c_and_count_memset(void *s, unsigned long pattern, : __memset_generic((s), (c), (count)))#define __HAVE_ARCH_MEMSET +extern void *memset (void *,int ,size_t ); +#ifndef CONFIG_FORTIFY_SOURCE #if (__GNUC__ >=4 )#define memset (s, c, count) __builtin_memset(s, c, count)#else
@@ -330,6 +338,7 @@ void *__constant_c_and_count_memset(void *s, unsigned long pattern, (count)) \ : __memset((s), (c), (count)))#endif +#endif /* !CONFIG_FORTIFY_SOURCE */ /* * find the first occurrence of byte 'c', or 1 past the area if none
arch/x86/include/asm/string_64.h +7 -0
@@ -31,6 +31,7 @@ static __always_inline void *__inline_memcpy(void *to, const void *from, size_textern void *memcpy (void *to,const void *from,size_t len);extern void *__memcpy (void *to,const void *from,size_t len); +#ifndef CONFIG_FORTIFY_SOURCE #ifndef CONFIG_KMEMCHECK #if (__GNUC__ ==4 && __GNUC_MINOR__ <3 ) || __GNUC__ <4 #define memcpy (dst, src, len) \
@@ -51,6 +52,7 @@ extern void *__memcpy(void *to, const void *from, size_t len);*/ #define memcpy (dst, src, len) __inline_memcpy((dst), (src), (len))#endif +#endif /* !CONFIG_FORTIFY_SOURCE */ #define __HAVE_ARCH_MEMSETvoid *memset (void *s,int c,size_t n);
@@ -77,6 +79,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
Andrew Morton
maintainerQuoted 5 lines · On Fri, 26 May 2017 05:54:04 -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.
Did we find a bug in drivers/infiniband/sw/rxe/rxe_resp.c?
i386 allmodconfig:
In file included from ./include/linux/bitmap.h:8:0,
from ./include/linux/cpumask.h:11,
from ./include/linux/mm_types_task.h:13,
from ./include/linux/mm_types.h:4,
from ./include/linux/kmemcheck.h:4,
from ./include/linux/skbuff.h:18,
from drivers/infiniband/sw/rxe/rxe_resp.c:34:In function 'memcpy',
inlined from 'send_atomic_ack.constprop' at drivers/infiniband/sw/rxe/rxe_resp.c:998:2,
inlined from 'acknowledge' at drivers/infiniband/sw/rxe/rxe_resp.c:1026:3,
inlined from 'rxe_responder' at drivers/infiniband/sw/rxe/rxe_resp.c:1286:10:./include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
If so, can you please interpret this for the infiniband developers?
Quoted 32 lines · Andrew Morton
On Fri, 26 May 2017 05:54:04 -0400 Daniel Micay <[email protected]
Quoted 9 lines
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.Did we find a bug in
drivers/infiniband/sw/rxe/rxe_resp.c?i386 allmodconfig:
In file included from
./include/linux/bitmap.h:8:0,from ./include/linux/cpumask.h:11, from ./include/linux/mm_types_task.h:13, from ./include/linux/mm_types.h:4, from ./include/linux/kmemcheck.h:4, from ./include/linux/skbuff.h:18, from drivers/infiniband/sw/rxe/rxe_resp.c:34:In function 'memcpy',
inlined from 'send_atomic_ack.constprop' atdrivers/infiniband/sw/rxe/rxe_resp.c:998:2,
inlined from 'acknowledge' atdrivers/infiniband/sw/rxe/rxe_resp.c:1026:3,
inlined from 'rxe_responder' atdrivers/infiniband/sw/rxe/rxe_resp.c:1286:10:./include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
Quoted 4 lines
__read_overflow2();If so, can you please interpret this for the infiniband developers?
It copies sizeof(skb->cb) bytes with memcpy which is 48 bytes since cb is a 48 byte char array in struct sk_buff. The source buffer is a struct rxe_pkt_info:
struct rxe_pkt_info {
struct rxe_dev *rxe; /* device that owns packet */
struct rxe_qp *qp; /* qp that owns packet */
struct rxe_send_wqe *wqe; /* send wqe */
u8 *hdr; /* points to bth */
u32 mask; /* useful info about pkt */
u32 psn; /* bth psn of packet */
u16 pkey_index; /* partition of pkt */
u16 paylen; /* length of bth - icrc */
u8 port_num; /* port pkt received on */
u8 opcode; /* bth opcode of packet */
u8 offset; /* bth offset from pkt->hdr */
};That looks like 32 bytes (1 byte of padding) on 32-bit and 48 bytes on 64-bit (1 byte of padding), so on 32-bit there's a read overflow of 16 bytes from the stack here.
Quoted 54 lines · Daniel Micay
Quoted 32 lines · Andrew Morton
On Fri, 26 May 2017 05:54:04 -0400 Daniel Micay <[email protected]
Quoted 9 lines
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.Did we find a bug in
drivers/infiniband/sw/rxe/rxe_resp.c?i386 allmodconfig:
In file included from
./include/linux/bitmap.h:8:0,from ./include/linux/cpumask.h:11, from ./include/linux/mm_types_task.h:13, from ./include/linux/mm_types.h:4, from ./include/linux/kmemcheck.h:4, from ./include/linux/skbuff.h:18, from drivers/infiniband/sw/rxe/rxe_resp.c:34:In function 'memcpy',
inlined from 'send_atomic_ack.constprop' atdrivers/infiniband/sw/rxe/rxe_resp.c:998:2,
inlined from 'acknowledge' atdrivers/infiniband/sw/rxe/rxe_resp.c:1026:3,
inlined from 'rxe_responder' atdrivers/infiniband/sw/rxe/rxe_resp.c:1286:10:./include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameterQuoted 4 lines
__read_overflow2();If so, can you please interpret this for the infiniband developers?
It copies
sizeof(skb->cb)bytes with memcpy which is 48 bytes since cb is a 48 byte char array instruct sk_buff. The source buffer is astruct rxe_pkt_info:struct
rxe_pkt_info{struct rxe_dev *rxe; /* device that owns packet */ struct rxe_qp *qp; /* qp that owns packet */ struct rxe_send_wqe *wqe; /* send wqe */ u8 *hdr; /* points to bth */ u32 mask; /* useful info about pkt */ u32 psn; /* bth psn of packet */ u16 pkey_index; /* partition of pkt */ u16 paylen; /* length of bth - icrc */ u8 port_num; /* port pkt received on */ u8 opcode; /* bth opcode of packet */ u8 offset; /* bth offset from pkt->hdr */
Quoted 5 lines
};
That looks like 32 bytes (1 byte of padding) on 32-bit and 48 bytes on 64-bit (1 byte of padding), so on 32-bit there's a read overflow of 16 bytes from the stack here.
This should work (untested):
(quoted diff) +0 -0
b/drivers/infiniband/sw/rxe/rxe_resp.c
index 23039768f541..7b226deb83bb 100644
drivers/infiniband/sw/rxe/rxe_resp.c +0 -0
@@ -995,7 +995,9 @@ static int send_atomic_ack(struct rxe_qp *qp,
struct rxe_pkt_info *pkt,
free_rd_atomic_resource(qp, res);
rxe_advance_resp_resource(qp);- memcpy(SKB_TO_PKT(skb), &ack_pkt, sizeof(skb->cb)); + memcpy(SKB_TO_PKT(skb), &ack_pkt, sizeof(ack_ptr)); + memset(SKB_TO_PKT(skb) + sizeof(ack_ptr), 0,
+ sizeof(skb->cb) - sizeof(ack_ptr));
res->type = RXE_ATOMIC_MASK;
res->atomic.skb = skb;Andrew, there are other fortify fixes too:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/fortify&id=af6b0151896240457ef0fdc18ace533c3d3fbb75
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/fortify&id=186eaf81b43bf90d6b533732fb11ad31ca27df9d
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/fortify&id=95d589f21b3aef757f0eb3d0224b78648a4b22d2
https://github.com/thestinger/linux-hardened/commit/576e64469b0c4634c007445c5f16bfde610b3600
Do you want me to resend these for you to carry, or reping maintainers? Other fixes have already landed in -next.
(And there are two arm64 fixes, too.)
-Kees
Signature · 2 lines
Kees Cook Pixel Security