From: Rasmus Villemoes <linux@rasmusvillemoes.dk> To: Emese Revfy <re.emese@gmail.com> Cc: kernel-hardening@lists.openwall.com, pageexec@freemail.hu, spender@grsecurity.net, mmarek@suse.com, keescook@chromium.org, linux-kernel@vger.kernel.org, yamada.masahiro@socionext.com, linux-kbuild@vger.kernel.org, minipli@ld-linux.so, linux@armlinux.org.uk, catalin.marinas@arm.com, david.brown@linaro.org, benh@kernel.crashing.org, tglx@linutronix.de, akpm@linux-foundation.org, jlayton@poochiereds.net, arnd@arndb.de Subject: Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Date: Tue, 28 Jun 2016 22:50:55 +0200 [thread overview] Message-ID: <874m8dhwb4.fsf@rasmusvillemoes.dk> (raw) In-Reply-To: <20160628133645.8f3cac0df4fc363e308426ac@gmail.com> (Emese Revfy's message of "Tue, 28 Jun 2016 13:36:45 +0200") On Tue, Jun 28 2016, Emese Revfy <re.emese@gmail.com> wrote: > The nocapture gcc attribute can be on functions only. > The attribute takes one or more unsigned integer constants as parameters > that specify the function argument(s) of const char* type to initify. > If the marked argument is a vararg then the plugin initifies > all vararg arguments. > > I couldn't test the arm, arm64 and powerpc architectures. > > Signed-off-by: Emese Revfy <re.emese@gmail.com> > --- > arch/arm/include/asm/string.h | 10 +++--- > arch/arm64/include/asm/string.h | 23 ++++++------ > arch/powerpc/include/asm/string.h | 19 +++++----- > arch/x86/boot/string.h | 4 +-- > arch/x86/include/asm/string_32.h | 21 +++++------ > arch/x86/include/asm/string_64.h | 18 +++++----- > arch/x86/kernel/hpet.c | 2 +- > include/asm-generic/bug.h | 6 ++-- > include/linux/compiler-gcc.h | 10 ++++-- > include/linux/compiler.h | 4 +++ > include/linux/fs.h | 5 +-- > include/linux/printk.h | 2 +- > include/linux/string.h | 73 ++++++++++++++++++++------------------- > 13 files changed, 107 insertions(+), 90 deletions(-) > > diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h > index cf4f3aa..3f68273 100644 > --- a/arch/arm/include/asm/string.h > +++ b/arch/arm/include/asm/string.h > @@ -7,19 +7,19 @@ > */ > > #define __HAVE_ARCH_STRRCHR > -extern char * strrchr(const char * s, int c); > +extern char * strrchr(const char * s, int c) __nocapture(1); > > #define __HAVE_ARCH_STRCHR > -extern char * strchr(const char * s, int c); > +extern char * strchr(const char * s, int c) __nocapture(1); > > #define __HAVE_ARCH_MEMCPY > -extern void * memcpy(void *, const void *, __kernel_size_t); > +extern void * memcpy(void *, const void *, __kernel_size_t) __nocapture(2); > Why not also mark he dest argument of the various strcpy/memcpy/memset functions as nocapture? It's no use for the initify plugin, but a static analysis tool could for example use it to (better) diagnose resource leaks (e.g., a buffer is kmalloc'ed and initialized with some *cpy, but then something goes wrong, and the buffer isn't freed on the error path). > > #define __HAVE_ARCH_STRLEN > extern __kernel_size_t strlen(const char *); Why not also mark strlen? I know that gcc optimizes strlen("literal") away, but, again, there might be other uses even when the argument is not a literal. One example is the plugin itself, which could deduce (or suggest) __nocapture for a given function parameter if the parameter is only passed on as __nocapture arguments. > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h > index 6f96247..4cdf266 100644 > --- a/include/asm-generic/bug.h > +++ b/include/asm-generic/bug.h > @@ -62,13 +62,13 @@ struct bug_entry { > * to provide better diagnostics. > */ > #ifndef __WARN_TAINT > -extern __printf(3, 4) > +extern __printf(3, 4) __nocapture(1, 3, 4) > void warn_slowpath_fmt(const char *file, const int line, > const char *fmt, ...); > -extern __printf(4, 5) > +extern __printf(4, 5) __nocapture(1, 4, 5) > void warn_slowpath_fmt_taint(const char *file, const int line, unsigned taint, > const char *fmt, ...); The 3,4 and 4,5 parts seem redundant when __printf automatically supplies those. > -extern void warn_slowpath_null(const char *file, const int line); > +extern __nocapture(1) void warn_slowpath_null(const char *file, const int line); > #define WANT_WARN_ON_SLOWPATH > #define __WARN() warn_slowpath_null(__FILE__, __LINE__) > #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg) > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h > index df88c0a..192cea4 100644 > --- a/include/linux/compiler-gcc.h > +++ b/include/linux/compiler-gcc.h > @@ -116,8 +116,10 @@ > */ > #define __pure __attribute__((pure)) > #define __aligned(x) __attribute__((aligned(x))) > -#define __printf(a, b) __attribute__((format(printf, a, b))) > -#define __scanf(a, b) __attribute__((format(scanf, a, b))) > +#define __printf(a, b) __attribute__((format(printf, a, b))) \ > + __nocapture(a, b) > +#define __scanf(a, b) __attribute__((format(scanf, a, b))) \ > + __nocapture(a, b) So obviously the output parameters for scanf are never going to be string literals, but I've already argued that one might as well put the __nocapture on all relevant pointer arguments while we're churning the headers, so keep this. > > -extern char *kstrdup(const char *s, gfp_t gfp) __malloc; > -extern const char *kstrdup_const(const char *s, gfp_t gfp); > -extern char *kstrndup(const char *s, size_t len, gfp_t gfp); > -extern void *kmemdup(const void *src, size_t len, gfp_t gfp); > +extern char *kstrdup(const char *s, gfp_t gfp) __malloc __nocapture(1); > +extern const char *kstrdup_const(const char *s, gfp_t gfp) __nocapture(1); OK, so this one is pretty dangerous, and probably wrong. If one does foo->bar = kstrdup_const(a-macro-that-might-be-a-string-literal) in an .init function, foo->bar will very likely become dangling. Come to think of it, I guess this means that __nocapture arguments must not only not be stashed anywhere, the return value cannot point (in)to the same object, which in turn then also disqualifies at least strchr(), memchr() and the haystack parameter of strstr(). And bummer, that kills my suggestion to add __nocapture to the dst parameters of *cpy, since they return that argument. Rasmus
WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk> To: Emese Revfy <re.emese@gmail.com> Cc: kernel-hardening@lists.openwall.com, pageexec@freemail.hu, spender@grsecurity.net, mmarek@suse.com, keescook@chromium.org, linux-kernel@vger.kernel.org, yamada.masahiro@socionext.com, linux-kbuild@vger.kernel.org, minipli@ld-linux.so, linux@armlinux.org.uk, catalin.marinas@arm.com, david.brown@linaro.org, benh@kernel.crashing.org, tglx@linutronix.de, akpm@linux-foundation.org, jlayton@poochiereds.net, arnd@arndb.de Subject: [kernel-hardening] Re: [PATCH v1 2/2] Mark functions with the __nocapture attribute Date: Tue, 28 Jun 2016 22:50:55 +0200 [thread overview] Message-ID: <874m8dhwb4.fsf@rasmusvillemoes.dk> (raw) In-Reply-To: <20160628133645.8f3cac0df4fc363e308426ac@gmail.com> (Emese Revfy's message of "Tue, 28 Jun 2016 13:36:45 +0200") On Tue, Jun 28 2016, Emese Revfy <re.emese@gmail.com> wrote: > The nocapture gcc attribute can be on functions only. > The attribute takes one or more unsigned integer constants as parameters > that specify the function argument(s) of const char* type to initify. > If the marked argument is a vararg then the plugin initifies > all vararg arguments. > > I couldn't test the arm, arm64 and powerpc architectures. > > Signed-off-by: Emese Revfy <re.emese@gmail.com> > --- > arch/arm/include/asm/string.h | 10 +++--- > arch/arm64/include/asm/string.h | 23 ++++++------ > arch/powerpc/include/asm/string.h | 19 +++++----- > arch/x86/boot/string.h | 4 +-- > arch/x86/include/asm/string_32.h | 21 +++++------ > arch/x86/include/asm/string_64.h | 18 +++++----- > arch/x86/kernel/hpet.c | 2 +- > include/asm-generic/bug.h | 6 ++-- > include/linux/compiler-gcc.h | 10 ++++-- > include/linux/compiler.h | 4 +++ > include/linux/fs.h | 5 +-- > include/linux/printk.h | 2 +- > include/linux/string.h | 73 ++++++++++++++++++++------------------- > 13 files changed, 107 insertions(+), 90 deletions(-) > > diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h > index cf4f3aa..3f68273 100644 > --- a/arch/arm/include/asm/string.h > +++ b/arch/arm/include/asm/string.h > @@ -7,19 +7,19 @@ > */ > > #define __HAVE_ARCH_STRRCHR > -extern char * strrchr(const char * s, int c); > +extern char * strrchr(const char * s, int c) __nocapture(1); > > #define __HAVE_ARCH_STRCHR > -extern char * strchr(const char * s, int c); > +extern char * strchr(const char * s, int c) __nocapture(1); > > #define __HAVE_ARCH_MEMCPY > -extern void * memcpy(void *, const void *, __kernel_size_t); > +extern void * memcpy(void *, const void *, __kernel_size_t) __nocapture(2); > Why not also mark he dest argument of the various strcpy/memcpy/memset functions as nocapture? It's no use for the initify plugin, but a static analysis tool could for example use it to (better) diagnose resource leaks (e.g., a buffer is kmalloc'ed and initialized with some *cpy, but then something goes wrong, and the buffer isn't freed on the error path). > > #define __HAVE_ARCH_STRLEN > extern __kernel_size_t strlen(const char *); Why not also mark strlen? I know that gcc optimizes strlen("literal") away, but, again, there might be other uses even when the argument is not a literal. One example is the plugin itself, which could deduce (or suggest) __nocapture for a given function parameter if the parameter is only passed on as __nocapture arguments. > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h > index 6f96247..4cdf266 100644 > --- a/include/asm-generic/bug.h > +++ b/include/asm-generic/bug.h > @@ -62,13 +62,13 @@ struct bug_entry { > * to provide better diagnostics. > */ > #ifndef __WARN_TAINT > -extern __printf(3, 4) > +extern __printf(3, 4) __nocapture(1, 3, 4) > void warn_slowpath_fmt(const char *file, const int line, > const char *fmt, ...); > -extern __printf(4, 5) > +extern __printf(4, 5) __nocapture(1, 4, 5) > void warn_slowpath_fmt_taint(const char *file, const int line, unsigned taint, > const char *fmt, ...); The 3,4 and 4,5 parts seem redundant when __printf automatically supplies those. > -extern void warn_slowpath_null(const char *file, const int line); > +extern __nocapture(1) void warn_slowpath_null(const char *file, const int line); > #define WANT_WARN_ON_SLOWPATH > #define __WARN() warn_slowpath_null(__FILE__, __LINE__) > #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg) > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h > index df88c0a..192cea4 100644 > --- a/include/linux/compiler-gcc.h > +++ b/include/linux/compiler-gcc.h > @@ -116,8 +116,10 @@ > */ > #define __pure __attribute__((pure)) > #define __aligned(x) __attribute__((aligned(x))) > -#define __printf(a, b) __attribute__((format(printf, a, b))) > -#define __scanf(a, b) __attribute__((format(scanf, a, b))) > +#define __printf(a, b) __attribute__((format(printf, a, b))) \ > + __nocapture(a, b) > +#define __scanf(a, b) __attribute__((format(scanf, a, b))) \ > + __nocapture(a, b) So obviously the output parameters for scanf are never going to be string literals, but I've already argued that one might as well put the __nocapture on all relevant pointer arguments while we're churning the headers, so keep this. > > -extern char *kstrdup(const char *s, gfp_t gfp) __malloc; > -extern const char *kstrdup_const(const char *s, gfp_t gfp); > -extern char *kstrndup(const char *s, size_t len, gfp_t gfp); > -extern void *kmemdup(const void *src, size_t len, gfp_t gfp); > +extern char *kstrdup(const char *s, gfp_t gfp) __malloc __nocapture(1); > +extern const char *kstrdup_const(const char *s, gfp_t gfp) __nocapture(1); OK, so this one is pretty dangerous, and probably wrong. If one does foo->bar = kstrdup_const(a-macro-that-might-be-a-string-literal) in an .init function, foo->bar will very likely become dangling. Come to think of it, I guess this means that __nocapture arguments must not only not be stashed anywhere, the return value cannot point (in)to the same object, which in turn then also disqualifies at least strchr(), memchr() and the haystack parameter of strstr(). And bummer, that kills my suggestion to add __nocapture to the dst parameters of *cpy, since they return that argument. Rasmus
next prev parent reply other threads:[~2016-06-28 20:51 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-28 11:34 [PATCH v1 0/2] Introduce the initify gcc plugin Emese Revfy 2016-06-28 11:34 ` [kernel-hardening] " Emese Revfy 2016-06-28 11:35 ` [PATCH v1 1/2] Add " Emese Revfy 2016-06-28 11:35 ` [kernel-hardening] " Emese Revfy 2016-06-28 21:05 ` Rasmus Villemoes 2016-06-28 21:05 ` [kernel-hardening] " Rasmus Villemoes 2016-06-29 14:50 ` Kees Cook 2016-06-29 14:50 ` [kernel-hardening] " Kees Cook 2016-06-29 14:50 ` Kees Cook 2016-06-29 19:03 ` Emese Revfy 2016-06-29 19:03 ` [kernel-hardening] " Emese Revfy 2016-06-28 11:36 ` [PATCH v1 2/2] Mark functions with the __nocapture attribute Emese Revfy 2016-06-28 11:36 ` [kernel-hardening] " Emese Revfy 2016-06-28 16:43 ` Joe Perches 2016-06-28 16:43 ` [kernel-hardening] " Joe Perches 2016-06-28 20:40 ` Emese Revfy 2016-06-28 20:40 ` [kernel-hardening] " Emese Revfy 2016-06-28 21:00 ` Joe Perches 2016-06-28 21:00 ` [kernel-hardening] " Joe Perches 2016-06-29 18:42 ` Emese Revfy 2016-06-29 18:42 ` [kernel-hardening] " Emese Revfy 2016-06-30 0:12 ` Joe Perches 2016-06-30 0:12 ` [kernel-hardening] " Joe Perches 2016-07-01 14:03 ` Emese Revfy 2016-07-01 14:03 ` [kernel-hardening] " Emese Revfy 2016-06-28 20:50 ` Rasmus Villemoes [this message] 2016-06-28 20:50 ` Rasmus Villemoes 2016-06-28 21:38 ` PaX Team 2016-06-28 21:38 ` [kernel-hardening] " PaX Team 2016-06-28 22:41 ` Rasmus Villemoes 2016-06-28 22:41 ` [kernel-hardening] " Rasmus Villemoes 2016-06-29 18:39 ` Emese Revfy 2016-06-29 18:39 ` [kernel-hardening] " Emese Revfy 2016-06-28 11:42 ` [PATCH v1 0/2] Introduce the initify gcc plugin Emese Revfy 2016-06-28 11:42 ` [kernel-hardening] " Emese Revfy 2016-06-28 12:57 ` [kernel-hardening] " Mark Rutland 2016-06-28 16:14 ` Emese Revfy 2016-06-28 20:46 ` Kees Cook 2016-06-28 20:46 ` Kees Cook 2016-06-29 8:21 ` Mark Rutland 2016-06-29 8:21 ` Mark Rutland 2016-06-29 17:52 ` Mark Rutland 2016-06-29 17:52 ` Mark Rutland 2016-06-29 18:28 ` Emese Revfy 2016-06-29 18:28 ` Emese Revfy 2016-06-28 16:35 ` Joe Perches 2016-06-28 16:35 ` [kernel-hardening] " Joe Perches 2016-06-28 18:48 ` Joe Perches 2016-06-28 18:48 ` [kernel-hardening] " Joe Perches 2016-06-28 19:02 ` Rasmus Villemoes 2016-06-28 19:02 ` [kernel-hardening] " Rasmus Villemoes 2016-06-28 20:29 ` Emese Revfy 2016-06-28 20:29 ` [kernel-hardening] " Emese Revfy 2016-06-28 17:00 ` Mathias Krause 2016-06-28 17:00 ` [kernel-hardening] " Mathias Krause 2016-06-28 20:29 ` Emese Revfy 2016-06-28 20:29 ` [kernel-hardening] " Emese Revfy 2016-06-28 21:49 ` Joe Perches 2016-06-28 21:49 ` [kernel-hardening] " Joe Perches 2016-06-28 22:07 ` Valdis.Kletnieks 2016-06-28 23:54 ` Joe Perches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=874m8dhwb4.fsf@rasmusvillemoes.dk \ --to=linux@rasmusvillemoes.dk \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=catalin.marinas@arm.com \ --cc=david.brown@linaro.org \ --cc=jlayton@poochiereds.net \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=minipli@ld-linux.so \ --cc=mmarek@suse.com \ --cc=pageexec@freemail.hu \ --cc=re.emese@gmail.com \ --cc=spender@grsecurity.net \ --cc=tglx@linutronix.de \ --cc=yamada.masahiro@socionext.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.