Skip to contentSkip to conversation

add the option of fortified string.h functions

PATCH Superseded Daniel Micay 3 participants 4 messages May 26, 2017 – Jun 3, 2017

Subsystems (8)

v4 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

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
index 2eb714c4639f..d0aa42907569 100644
@@ -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
index b3c5a5f030ce..43691238a21d 100644
@@ -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
index 3d3e8353ee5c..e9ee84873de5 100644
@@ -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_MEMMOVE
 void *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_MEMCHR
 extern 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
index 733bae07fb29..309fe644569f 100644
@@ -31,6 +31,7 @@ static __always_inline void *__inline_memcpy(void *to, const void *from, size_t
 extern 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_MEMSET
 void *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
index 1c1fc9187b05..a6ee1955a701 100644
@@ -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
index 93027fdf47d1..0e5035d720ce 100644
@@ -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
maintainer
#1 lore raw
Quoted 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.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.

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?

#2 lore raw
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.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.

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

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.

#3 lore raw
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.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.

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

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 */
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