kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-08 18:57:22 +00:00
Code Issues Releases Packages Activity
linux/tools/include/nolibc/stackprotector.h

56 lines
1.6 KiB
Raw Normal View History

tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: add autodetection for stackprotector support The stackprotector support in nolibc should be enabled iff it is also enabled in the compiler. Use the preprocessor defines added by gcc and clang if stackprotector support is enable to automatically do so in nolibc. This completely removes the need for any user-visible API. To avoid inlining the lengthy preprocessor check into every user introduce a new header compiler.h that abstracts the logic away. As the define NOLIBC_STACKPROTECTOR is now not user-relevant anymore prefix it with an underscore. Suggested-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/lkml/20230520133237.GA27501@1wt.eu/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-05-21 11:36:34 +02:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: add option to disable runtime In principle, it is possible to use nolibc for only some object files in a program. In that case, the startup code in _start and _start_c is not going to be used. Add the NOLIBC_NO_RUNTIME compile time option to disable it entirely and also remove anything that depends on it. Doing this avoids warnings from modpost for UML as the _start_c code references the main function from the .init.text section while it is not inside .init itself. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2025-09-24 16:20:54 +02:00
tools/nolibc: add autodetection for stackprotector support The stackprotector support in nolibc should be enabled iff it is also enabled in the compiler. Use the preprocessor defines added by gcc and clang if stackprotector support is enable to automatically do so in nolibc. This completely removes the need for any user-visible API. To avoid inlining the lengthy preprocessor check into every user introduce a new header compiler.h that abstracts the logic away. As the define NOLIBC_STACKPROTECTOR is now not user-relevant anymore prefix it with an underscore. Suggested-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/lkml/20230520133237.GA27501@1wt.eu/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-05-21 11:36:34 +02:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: add prototypes for non-static functions With -Wmissing-prototypes the compiler will warn about non-static functions which don't have a prototype defined. This warning doesn't make much sense for nolibc itself but for user code it is still useful. To pacify the compiler add prototypes next to the function definitions, similar to how it is handled elsewhere in the kernel. Acked-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20250123-nolibc-prototype-v1-1-e1afc5c1999a@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2025-01-23 21:10:42 +01:00
tools/nolibc: stackprotector: mark implicitly used symbols as used During LTO the references from the compiler-generated prologue and epilogues to the stack protector symbols are not visible and the symbols are removed. This will then lead to errors during linking. As those symbols are already #ifdeffed-out if unused mark them as "used" to prevent their removal. Acked-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20240812-nolibc-lto-v2-2-736af7bbefa8@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2024-08-12 22:50:18 +02:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: rename my_syscallX() to __nolibc_syscallX() The naming convention of the my_syscallX() macros is a bit unfortunate. They may conflict with application code and the name is very generic. Switch to __nolibc_syscallX(). The leading underscores place the symbols in the implementation-defined namespace, avoiding conflicting names. It is also clearer that these are non-standard extensions from nolibc. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260223-nolibc-namespacing-v1-1-52574ffebb2c@weissschuh.net
2026-02-23 22:40:14 +01:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: add prototypes for non-static functions With -Wmissing-prototypes the compiler will warn about non-static functions which don't have a prototype defined. This warning doesn't make much sense for nolibc itself but for user code it is still useful. To pacify the compiler add prototypes next to the function definitions, similar to how it is handled elsewhere in the kernel. Acked-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20250123-nolibc-prototype-v1-1-e1afc5c1999a@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2025-01-23 21:10:42 +01:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: stackprotector: mark implicitly used symbols as used During LTO the references from the compiler-generated prologue and epilogues to the stack protector symbols are not visible and the symbols are removed. This will then lead to errors during linking. As those symbols are already #ifdeffed-out if unused mark them as "used" to prevent their removal. Acked-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20240812-nolibc-lto-v2-2-736af7bbefa8@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2024-08-12 22:50:18 +02:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: Rename __no_stack_protector to __nolibc_no_stack_protector To avoid polluting the namespace rename __no_stack_protector to __nolibc_no_stack_protector so its now within the nolibc umbrella. Suggested-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260425111315.3191461-2-daniel@thingy.jp Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2026-04-25 20:13:14 +09:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: stackprotector: Avoid stalling program startup if crng is not init yet We are using the getrandom syscall to get a random seed for the stack protector canary but we are calling it with no flags which means it'll block until there is some real randomness to return. This means that if the crng is not ready yet program startup will block and if you are unlucky that could be for a long time and look like the program has crashed. Even if the call to getrandom does not yield any random data, we will still initialize the canary. Fixes: 7188d4637e95 ("tools/nolibc: add support for stack protector") Signed-off-by: Daniel Palmer <daniel@thingy.jp> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260522090726.726985-1-daniel@thingy.jp Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2026-05-22 18:07:26 +09:00
tools/nolibc: ensure stack protector guard is never zero The all-zero pattern is one of the more probable out-of-bound writes so add a special case to not accidentally accept it. Also it enables the reliable detection of stack protector initialization during testing. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-05-21 11:36:31 +02:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: stackprotector.h: add empty __stack_chk_init for !_NOLIBC_STACKPROTECTOR Let's define an empty __stack_chk_init for the !_NOLIBC_STACKPROTECTOR branch. This allows to remove #ifdef around every call of __stack_chk_init(). Signed-off-by: Zhangjin Wu <falcon@tinylab.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
2023-07-16 02:22:15 +08:00
tools/nolibc: stackprotector.h: make __stack_chk_init static This allows to generate smaller text/data/dec size. As the _start_c() function added by crt.h, __stack_chk_init() is called from _start_c() instead of the assembly _start. So, it is able to mark it with static now. Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Zhangjin Wu <falcon@tinylab.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
2023-08-05 14:12:06 +08:00
tools/nolibc: add autodetection for stackprotector support The stackprotector support in nolibc should be enabled iff it is also enabled in the compiler. Use the preprocessor defines added by gcc and clang if stackprotector support is enable to automatically do so in nolibc. This completely removes the need for any user-visible API. To avoid inlining the lengthy preprocessor check into every user introduce a new header compiler.h that abstracts the logic away. As the define NOLIBC_STACKPROTECTOR is now not user-relevant anymore prefix it with an underscore. Suggested-by: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/lkml/20230520133237.GA27501@1wt.eu/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-05-21 11:36:34 +02:00
tools/nolibc: add option to disable runtime In principle, it is possible to use nolibc for only some object files in a program. In that case, the startup code in _start and _start_c is not going to be used. Add the NOLIBC_NO_RUNTIME compile time option to disable it entirely and also remove anything that depends on it. Doing this avoids warnings from modpost for UML as the _start_c code references the main function from the .init.text section while it is not inside .init itself. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2025-09-24 16:20:54 +02:00
tools/nolibc: add support for stack protector This is useful when using nolibc for security-critical tools. Using nolibc has the advantage that the code is easily auditable and sandboxable with seccomp as no unexpected syscalls are used. Using compiler-assistent stack protection provides another security mechanism. For this to work the compiler and libc have to collaborate. This patch adds the following parts to nolibc that are required by the compiler: * __stack_chk_guard: random sentinel value * __stack_chk_fail: handler for detected stack smashes In addition an initialization function is added that randomizes the sentinel value. Only support for global guards is implemented. Register guards are useful in multi-threaded context which nolibc does not provide support for. Link: https://lwn.net/Articles/584225/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-03-25 16:45:12 +01:00
tools/nolibc: use C89 comment syntax Most of nolibc is already using C89 comments. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2023-04-06 21:54:49 +00:00