From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Willy Tarreau <w@1wt.eu>
Cc: Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH RFC 4/5] tools/nolibc: add support for stack protector
Date: Sun, 12 Mar 2023 23:06:58 +0000 [thread overview]
Message-ID: <68b4b33d-711b-4b5d-b932-6beceffbcf28@t-8ch.de> (raw)
In-Reply-To: <ZA3MC89PEq058cdo@1wt.eu>
On Sun, Mar 12, 2023 at 01:56:43PM +0100, Willy Tarreau wrote:
> Hi Thomas,
>
> thanks for this patchset. I must confess it's not very clear to me which
> class of programs using nolibc could benefit from stack protection, but
> if you think it can improve the overall value (even if just by allowing
> to test more combinations), I'm fine with this given that it doesn't
> remove anything.
I forgot the rationale, will add it properly to the next revision:
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.
> I'm having a few comments below:
>
> On Tue, Mar 07, 2023 at 10:22:33PM +0000, Thomas Weißschuh wrote:
> > diff --git a/tools/include/nolibc/stackprotector.h b/tools/include/nolibc/stackprotector.h
> > new file mode 100644
> > index 000000000000..ca1360b7afd8
> > --- /dev/null
> > +++ b/tools/include/nolibc/stackprotector.h
> > @@ -0,0 +1,48 @@
> > +/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
> > +/*
> > + * Stack protector support for NOLIBC
> > + * Copyright (C) 2023 Thomas Weißschuh <linux@weissschuh.net>
> > + */
> > +
> > +#ifndef _NOLIBC_STACKPROTECTOR_H
> > +#define _NOLIBC_STACKPROTECTOR_H
> > +
> > +#include "arch.h"
> > +
> > +#if defined(NOLIBC_STACKPROTECTOR)
> > +
> > +#if !defined(__ARCH_SUPPORTS_STACK_PROTECTOR)
> > +#error "nolibc does not support stack protectors on this arch"
> > +#endif
> > +
> > +#include "sys.h"
> > +#include "stdlib.h"
> > +
> > +__attribute__((weak,noreturn,section(".text.nolibc_stack_chk")))
> > +void __stack_chk_fail(void)
> > +{
> > + write(STDERR_FILENO, "!!Stack smashing detected!!\n", 28);
> > + abort();
> > +}
>
> Don't you think you should call the syscall directly here like you
> did for __stack_chk_init() and/or declare the function with the
> no_stackprotector attribute ? I'm wondering if there could be a
> risk that it fails again if called from a bad condition. If you're
> certain it cannot, maybe just explain it in a 2-line comment above
> the function so that others don't ask the same in the future.
Good point. It probably works because the compiler decided to inline the
call. But syscalls are more robust, I'll change that.
> > +__attribute__((weak,no_stack_protector,section(".text.nolibc_stack_chk")))
> > +void __stack_chk_init(void)
> > +{
> > + // raw syscall assembly as calling a function would trigger the
> > + // stackprotector itself
> > + my_syscall3(__NR_getrandom, &__stack_chk_guard, sizeof(__stack_chk_guard), 0);
>
> For full-line comments, the regular C-style "/* */" is preferred (and
> please also use the multi-line format when needed). "//" tends to be
> reserved for short ones at the end of a line.
Of course, will be changed.
> > + // a bit more randomness in case getrandom() fails
> > + __stack_chk_guard |= (uintptr_t) &__stack_chk_guard;
>
> Using |= will in fact remove randomness rather than add, because it
> will turn some zero bits to ones but not the opposite. Maybe you'd
> want to use "^=" or "+=" instead ?
Indeed, will change that.
next prev parent reply other threads:[~2023-03-12 23:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 22:22 [PATCH RFC 0/5] " Thomas Weißschuh
2023-03-07 22:22 ` [PATCH RFC 1/5] tools/nolibc: add definitions for standard fds Thomas Weißschuh
2023-03-07 22:22 ` [PATCH RFC 2/5] tools/nolibc: add helpers for wait() signal exits Thomas Weißschuh
2023-03-07 22:22 ` [PATCH RFC 3/5] tools/nolibc: tests: constify test_names Thomas Weißschuh
2023-03-07 22:22 ` [PATCH RFC 4/5] tools/nolibc: add support for stack protector Thomas Weißschuh
2023-03-12 12:56 ` Willy Tarreau
2023-03-12 23:06 ` Thomas Weißschuh [this message]
2023-03-13 3:24 ` Willy Tarreau
2023-03-07 22:22 ` [PATCH RFC 5/5] tools/nolibc: tests: add test for -fstack-protector Thomas Weißschuh
2023-03-12 13:07 ` Willy Tarreau
2023-03-12 23:12 ` Thomas Weißschuh
2023-03-13 3:08 ` Willy Tarreau
2023-03-18 16:49 ` Thomas Weißschuh
2023-03-19 13:58 ` 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=68b4b33d-711b-4b5d-b932-6beceffbcf28@t-8ch.de \
--to=linux@weissschuh.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=w@1wt.eu \
/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
all inboxes | Powered by JetHome®