From: Willy Tarreau <w@1wt.eu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux@weissschuh.net, linux-kernel@vger.kernel.org,
Willy Tarreau <w@1wt.eu>
Subject: [PATCH 0/8] tools/nolibc: add support for stack protector
Date: Sat, 25 Mar 2023 16:45:08 +0100 [thread overview]
Message-ID: <20230325154516.7995-1-w@1wt.eu> (raw)
Hello Paul,
This is essentially Thomas' work so instead of paraphrasing his work,
I'm pasting his description below. I've tested his changes on all
supported archs, applied a tiny modification with his permission
to continue to support passing CFLAGS, and for me this is all fine.
In a short summary this adds support for stack protector to i386 and
x86_64 in nolibc, and the accompanying test to the selftest program.
A new test category was added, "protection", which currently has a
single test. Archs that support it will report "OK" there and those
that do not will report "SKIPPED", as is already the case for tests
that cannot be run.
This was applied on top of your dev.2023.03.20a branch. I'm reasonably
confident with the nature of the changes, so if your queue for 6.4 is
not closed yet, it can be a good target, otherwise 6.5 will be fine as
well.
Thanks in advance!
Willy
Thomas' description below:
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/
Thomas Weißschuh (8):
tools/nolibc: add definitions for standard fds
tools/nolibc: add helpers for wait() signal exits
tools/nolibc: tests: constify test_names
tools/nolibc: add support for stack protector
tools/nolibc: tests: fold in no-stack-protector cflags
tools/nolibc: tests: add test for -fstack-protector
tools/nolibc: i386: add stackprotector support
tools/nolibc: x86_64: add stackprotector support
tools/include/nolibc/Makefile | 4 +-
tools/include/nolibc/arch-i386.h | 7 ++-
tools/include/nolibc/arch-x86_64.h | 5 ++
tools/include/nolibc/nolibc.h | 1 +
tools/include/nolibc/stackprotector.h | 53 ++++++++++++++++
tools/include/nolibc/types.h | 2 +
tools/include/nolibc/unistd.h | 5 ++
tools/testing/selftests/nolibc/Makefile | 11 +++-
tools/testing/selftests/nolibc/nolibc-test.c | 64 +++++++++++++++++++-
9 files changed, 144 insertions(+), 8 deletions(-)
create mode 100644 tools/include/nolibc/stackprotector.h
--
2.17.5
next reply other threads:[~2023-03-25 15:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-25 15:45 Willy Tarreau [this message]
2023-03-25 15:45 ` [PATCH 1/8] tools/nolibc: add definitions for standard fds Willy Tarreau
2023-03-25 15:45 ` [PATCH 2/8] tools/nolibc: add helpers for wait() signal exits Willy Tarreau
2023-03-25 15:45 ` [PATCH 3/8] tools/nolibc: tests: constify test_names Willy Tarreau
2023-03-25 15:45 ` [PATCH 4/8] tools/nolibc: add support for stack protector Willy Tarreau
2023-03-25 15:45 ` [PATCH 5/8] tools/nolibc: tests: fold in no-stack-protector cflags Willy Tarreau
2023-03-25 15:45 ` [PATCH 6/8] tools/nolibc: tests: add test for -fstack-protector Willy Tarreau
2023-03-25 15:45 ` [PATCH 7/8] tools/nolibc: i386: add stackprotector support Willy Tarreau
2023-03-25 15:45 ` [PATCH 8/8] tools/nolibc: x86_64: " Willy Tarreau
2023-03-26 4:36 ` [PATCH 0/8] tools/nolibc: add support for stack protector Paul E. McKenney
2023-03-26 6:20 ` Willy Tarreau
2023-03-26 15:13 ` Paul E. McKenney
2023-03-26 15:17 ` Willy Tarreau
2023-03-26 15:26 ` Paul E. McKenney
2023-03-26 15:28 ` Willy Tarreau
2023-03-26 15:45 ` Paul E. McKenney
2023-03-26 16:00 ` Willy Tarreau
2023-03-26 16:05 ` Willy Tarreau
2023-03-26 16:55 ` Willy Tarreau
2023-03-26 18:00 ` Paul E. McKenney
2023-03-27 3:41 ` Paul E. McKenney
2023-03-27 4:04 ` Willy Tarreau
2023-03-26 15:30 ` Paul E. McKenney
2023-03-26 15:42 ` Willy Tarreau
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=20230325154516.7995-1-w@1wt.eu \
--to=w@1wt.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=paulmck@kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox