* [PATCH] string.h: work around for increased stack usage
@ 2017-12-05 21:51 Arnd Bergmann
2017-12-05 22:02 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Arnd Bergmann @ 2017-12-05 21:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Mauro Carvalho Chehab, linux-media, kasan-dev,
Dmitry Vyukov, Alexander Potapenko, Andrey Ryabinin,
linux-kbuild, Arnd Bergmann, stable, Daniel Micay,
Greg Kroah-Hartman, Martin Wilck, Dan Williams, linux-kernel
The hardened strlen() function causes rather large stack usage in at
least one file in the kernel, in particular when CONFIG_KASAN is enabled:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
Analyzing this problem led to the discovery that gcc fails to merge the
stack slots for the i2c_board_info[] structures after we strlcpy() into
them, due to the 'noreturn' attribute on the source string length check.
I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
since it is relatively easy to work around, and it gets triggered rarely.
An earlier workaround I did added an empty inline assembly statement
before the call to fortify_panic(), which works surprisingly well,
but is really ugly and unintuitive.
This is a new approach to the same problem, this time addressing it by
not calling the 'extern __real_strnlen()' function for string constants
where __builtin_strlen() is a compile-time constant and therefore known
to be safe. We do this by checking if the last character in the string
is a compile-time constant '\0'. If it is, we can assume that
strlen() of the string is also constant. As a side-effect, this should
also improve the object code output for any other call of strlen()
on a string constant.
Cc: stable@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: https://patchwork.kernel.org/patch/9980413/
Link: https://patchwork.kernel.org/patch/9974047/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v3: don't use an asm barrier but use a constant string change.
Aside from two other patches for drivers/media that I sent last week,
this should fix all stack frames above 2KB, once all three are merged,
I'll send the patch to re-enable the warning.
---
include/linux/string.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index 410ecf17de3c..e5cc3f27f6e0 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -259,7 +259,8 @@ __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)
+ if (p_size == (size_t)-1 ||
+ (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
ret = strnlen(p, p_size);
if (p_size <= ret)
--
2.9.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] string.h: work around for increased stack usage
2017-12-05 21:51 [PATCH] string.h: work around for increased stack usage Arnd Bergmann
@ 2017-12-05 22:02 ` Andrew Morton
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Morton @ 2017-12-05 22:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kees Cook, Mauro Carvalho Chehab, linux-media, kasan-dev,
Dmitry Vyukov, Alexander Potapenko, Andrey Ryabinin,
linux-kbuild, stable, Daniel Micay, Greg Kroah-Hartman,
Martin Wilck, Dan Williams, linux-kernel
On Tue, 5 Dec 2017 22:51:19 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> The hardened strlen() function causes rather large stack usage in at
> least one file in the kernel, in particular when CONFIG_KASAN is enabled:
>
> drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
> drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
>
> Analyzing this problem led to the discovery that gcc fails to merge the
> stack slots for the i2c_board_info[] structures after we strlcpy() into
> them, due to the 'noreturn' attribute on the source string length check.
>
> I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
> since it is relatively easy to work around, and it gets triggered rarely.
> An earlier workaround I did added an empty inline assembly statement
> before the call to fortify_panic(), which works surprisingly well,
> but is really ugly and unintuitive.
>
> This is a new approach to the same problem, this time addressing it by
> not calling the 'extern __real_strnlen()' function for string constants
> where __builtin_strlen() is a compile-time constant and therefore known
> to be safe. We do this by checking if the last character in the string
> is a compile-time constant '\0'. If it is, we can assume that
> strlen() of the string is also constant. As a side-effect, this should
> also improve the object code output for any other call of strlen()
> on a string constant.
>
> Cc: stable@vger.kernel.org
I'll add
Fixes: 6974f0c4555 ("include/linux/string.h: add the option of fortified string.h functions")
to simplify stable@'s life.
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
> Link: https://patchwork.kernel.org/patch/9980413/
> Link: https://patchwork.kernel.org/patch/9974047/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> ...
>
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -259,7 +259,8 @@ __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)
> + if (p_size == (size_t)-1 ||
> + (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
> return __builtin_strlen(p);
> ret = strnlen(p, p_size);
> if (p_size <= ret)
Let's have some sympathy for our poor readers?
--- a/include/linux/string.h~stringh-work-around-for-increased-stack-usage-fix
+++ a/include/linux/string.h
@@ -259,6 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen(
{
__kernel_size_t ret;
size_t p_size = __builtin_object_size(p, 0);
+
+ /* Work around gcc excess stack consumption issue */
if (p_size == (size_t)-1 ||
(__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
_
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] string.h: work around for increased stack usage
2017-10-02 8:40 ` [PATCH] string.h: work around for increased stack usage Arnd Bergmann
@ 2017-10-03 18:10 ` kbuild test robot
2017-10-02 14:07 ` Andrey Ryabinin
2017-10-03 18:10 ` kbuild test robot
2 siblings, 0 replies; 7+ messages in thread
From: kbuild test robot @ 2017-10-03 18:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kbuild-all, Andrey Ryabinin, David Laight, Mauro Carvalho Chehab,
David S . Miller, Alexander Potapenko, Dmitry Vyukov,
Masahiro Yamada, Andrew Morton, Kees Cook, Geert Uytterhoeven,
Greg Kroah-Hartman, linux-media @ vger . kernel . org,
linux-kernel @ vger . kernel . org,
kasan-dev @ googlegroups . com,
linux-kbuild @ vger . kernel . org, Arnd Bergmann
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
Hi Arnd,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/string-h-work-around-for-increased-stack-usage/20171003-210611
config: x86_64-randconfig-ws0-10040032 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from lib/string.c:23:0:
>> include/linux/string.h:235:2: error: expected identifier or '(' before 'do'
do { \
^
>> lib/string.c:1048:6: note: in expansion of macro 'fortify_panic'
void fortify_panic(const char *name)
^
>> include/linux/string.h:238:4: error: expected identifier or '(' before 'while'
} while (0)
^
>> lib/string.c:1048:6: note: in expansion of macro 'fortify_panic'
void fortify_panic(const char *name)
^
vim +235 include/linux/string.h
231
232 /* work around GCC PR82365 */
233 #if defined(CONFIG_KASAN) && !defined(__clang__) && GCC_VERSION <= 80000
234 #define fortify_panic(x) \
> 235 do { \
236 asm volatile(""); \
237 fortify_panic(x); \
> 238 } while (0)
239 #endif
240
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32772 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] string.h: work around for increased stack usage
@ 2017-10-03 18:10 ` kbuild test robot
0 siblings, 0 replies; 7+ messages in thread
From: kbuild test robot @ 2017-10-03 18:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kbuild-all, Andrey Ryabinin, David Laight, Mauro Carvalho Chehab,
David S . Miller, Alexander Potapenko, Dmitry Vyukov,
Masahiro Yamada, Andrew Morton, Kees Cook, Geert Uytterhoeven,
Greg Kroah-Hartman, linux-media @ vger . kernel . org,
linux-kernel @ vger . kernel . org,
kasan-dev @ googlegroups . com,
linux-kbuild @ vger . kernel . org
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
Hi Arnd,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Arnd-Bergmann/string-h-work-around-for-increased-stack-usage/20171003-210611
config: x86_64-randconfig-ws0-10040032 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from lib/string.c:23:0:
>> include/linux/string.h:235:2: error: expected identifier or '(' before 'do'
do { \
^
>> lib/string.c:1048:6: note: in expansion of macro 'fortify_panic'
void fortify_panic(const char *name)
^
>> include/linux/string.h:238:4: error: expected identifier or '(' before 'while'
} while (0)
^
>> lib/string.c:1048:6: note: in expansion of macro 'fortify_panic'
void fortify_panic(const char *name)
^
vim +235 include/linux/string.h
231
232 /* work around GCC PR82365 */
233 #if defined(CONFIG_KASAN) && !defined(__clang__) && GCC_VERSION <= 80000
234 #define fortify_panic(x) \
> 235 do { \
236 asm volatile(""); \
237 fortify_panic(x); \
> 238 } while (0)
239 #endif
240
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32772 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] string.h: work around for increased stack usage
2017-10-02 8:40 ` [PATCH] string.h: work around for increased stack usage Arnd Bergmann
2017-10-02 9:02 ` Arnd Bergmann
@ 2017-10-02 14:07 ` Andrey Ryabinin
2017-10-03 18:10 ` kbuild test robot
2 siblings, 0 replies; 7+ messages in thread
From: Andrey Ryabinin @ 2017-10-02 14:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Laight, Mauro Carvalho Chehab, David S . Miller,
Alexander Potapenko, Dmitry Vyukov, Masahiro Yamada,
Andrew Morton, Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media @ vger . kernel . org,
linux-kernel @ vger . kernel . org,
kasan-dev @ googlegroups . com,
linux-kbuild @ vger . kernel . org
On 10/02/2017 11:40 AM, Arnd Bergmann wrote:
> The hardened strlen() function causes rather large stack usage
> in at least one file in the kernel when CONFIG_KASAN is enabled:
>
> drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
> drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
>
> Analyzing this problem led to the discovery that gcc fails to
> merge the stack slots for the i2c_board_info[] structures after
> we strlcpy() into them, due to the 'noreturn' attribute on the
> source string length check.
>
> The compiler behavior should get fixed in gcc-8, but for users
> of existing gcc versions, we can work around it using an empty
> inline assembly statement before the call to fortify_panic().
>
> The workaround is unfortunately very ugly, and I tried my best
> to limit it being applied to affected versions of gcc when
> KASAN is used. Alternative suggestions welcome.
>
I don't have a really strong preference, so this approach is fine by me,
but s/strlcpy/[strncpy|memcpy] approach seems a little better to me, because it's not ugly.
This ugly workaround would make more sense if we a had lot of cases like in em28xx_dvb_init().
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> include/linux/string.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index c7a1132cdc93..1bf5ecdf8e01 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -228,6 +228,16 @@ static inline const char *kbasename(const char *path)
> #define __RENAME(x) __asm__(#x)
>
> void fortify_panic(const char *name) __noreturn __cold;
> +
> +/* work around GCC PR82365 */
> +#if defined(CONFIG_KASAN) && !defined(__clang__) && GCC_VERSION <= 80000
> +#define fortify_panic(x) \
> + do { \
> + asm volatile(""); \
> + fortify_panic(x); \
> + } while (0)
> +#endif
> +
> 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 __read_overflow3(void) __compiletime_error("detected read beyond size of object passed as 3rd parameter");
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] string.h: work around for increased stack usage
2017-10-02 8:40 ` [PATCH] string.h: work around for increased stack usage Arnd Bergmann
@ 2017-10-02 9:02 ` Arnd Bergmann
2017-10-02 14:07 ` Andrey Ryabinin
2017-10-03 18:10 ` kbuild test robot
2 siblings, 0 replies; 7+ messages in thread
From: Arnd Bergmann @ 2017-10-02 9:02 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: David Laight, Mauro Carvalho Chehab, David S . Miller,
Alexander Potapenko, Dmitry Vyukov, Masahiro Yamada,
Andrew Morton, Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media @ vger . kernel . org,
linux-kernel @ vger . kernel . org,
kasan-dev @ googlegroups . com,
linux-kbuild @ vger . kernel . org, Arnd Bergmann
On Mon, Oct 2, 2017 at 10:40 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> void fortify_panic(const char *name) __noreturn __cold;
> +
> +/* work around GCC PR82365 */
> +#if defined(CONFIG_KASAN) && !defined(__clang__) && GCC_VERSION <= 80000
> +#define fortify_panic(x) \
> + do { \
> + asm volatile(""); \
> + fortify_panic(x); \
> + } while (0)
> +#endif
This broke the build for the fortify_panic() definition in lib/string.c which
clashes with the macro. I've fixed it locally by renaming it to __fortify_panic,
but won't post the fixed version until I get some feedback on the basic
approach.
Arnd
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] string.h: work around for increased stack usage
2017-10-02 8:33 [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN Arnd Bergmann
@ 2017-10-02 8:40 ` Arnd Bergmann
2017-10-02 9:02 ` Arnd Bergmann
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Arnd Bergmann @ 2017-10-02 8:40 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: David Laight, Mauro Carvalho Chehab, David S . Miller,
Alexander Potapenko, Dmitry Vyukov, Masahiro Yamada,
Andrew Morton, Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media @ vger . kernel . org,
linux-kernel @ vger . kernel . org,
kasan-dev @ googlegroups . com,
linux-kbuild @ vger . kernel . org, Arnd Bergmann
The hardened strlen() function causes rather large stack usage
in at least one file in the kernel when CONFIG_KASAN is enabled:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
Analyzing this problem led to the discovery that gcc fails to
merge the stack slots for the i2c_board_info[] structures after
we strlcpy() into them, due to the 'noreturn' attribute on the
source string length check.
The compiler behavior should get fixed in gcc-8, but for users
of existing gcc versions, we can work around it using an empty
inline assembly statement before the call to fortify_panic().
The workaround is unfortunately very ugly, and I tried my best
to limit it being applied to affected versions of gcc when
KASAN is used. Alternative suggestions welcome.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/string.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index c7a1132cdc93..1bf5ecdf8e01 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -228,6 +228,16 @@ static inline const char *kbasename(const char *path)
#define __RENAME(x) __asm__(#x)
void fortify_panic(const char *name) __noreturn __cold;
+
+/* work around GCC PR82365 */
+#if defined(CONFIG_KASAN) && !defined(__clang__) && GCC_VERSION <= 80000
+#define fortify_panic(x) \
+ do { \
+ asm volatile(""); \
+ fortify_panic(x); \
+ } while (0)
+#endif
+
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 __read_overflow3(void) __compiletime_error("detected read beyond size of object passed as 3rd parameter");
--
2.9.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-12-05 22:02 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-05 21:51 [PATCH] string.h: work around for increased stack usage Arnd Bergmann
2017-12-05 22:02 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2017-10-02 8:33 [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN Arnd Bergmann
2017-10-02 8:40 ` [PATCH] string.h: work around for increased stack usage Arnd Bergmann
2017-10-02 9:02 ` Arnd Bergmann
2017-10-02 14:07 ` Andrey Ryabinin
2017-10-03 18:10 ` kbuild test robot
2017-10-03 18:10 ` kbuild test robot
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.