GNU/Weeb Mailing List <[email protected]>
 help / color / mirror / Atom feed
From: Ammar Faizi <[email protected]>
To: "Thomas Weißschuh" <[email protected]>
Cc: Jens Axboe <[email protected]>,
	Alviro Iskandar Setiawan <[email protected]>,
	Guillem Jover <[email protected]>,
	Jeff Moyer <[email protected]>,
	Stefan Hajnoczi <[email protected]>,
	Michael William Jonathan <[email protected]>,
	Matthew Patrick <[email protected]>,
	io-uring Mailing List <[email protected]>,
	Linux Kernel Mailing List <[email protected]>,
	GNU/Weeb Mailing List <[email protected]>
Subject: Re: [RFC PATCH liburing v1 3/3] src/Makefile: Allow using stack protector with libc
Date: Fri, 23 Jun 2023 05:49:49 +0700	[thread overview]
Message-ID: <ZJTQDaAsN/[email protected]> (raw)
In-Reply-To: <[email protected]>

On Thu, Jun 22, 2023 at 07:57:38PM +0200, Thomas Weißschuh wrote:
> There are patches in the pipeline that enable stackprotector support for
> nolibc [0]. They should land in 6.5.

That's interesting. I haven't been following Willy's tree for a while.
Hope 6.4 stable goes well by the end of this week.

> It only supports "global" mode and not per-thread-data.
> But as nolibc does not support threads anyways that should not matter.
> A compiler flag has to be passed though, but that can be automated [1].
> 
> So the -fno-stack-protector can probably be removed completely.
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/tree/tools/include/nolibc/stackprotector.h?h=dev.2023.06.16a
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/tree/tools/testing/selftests/nolibc/Makefile?h=dev.2023.06.16a#n81

This is a bit problematic because liburing.so and liburing.a must also
be compatible with apps that use libc. Note that liburing nolibc is also
used by apps that use libc.

The problem when an app uses libc.so and liburing.a:

Stack-protector functions from liburing nolibc will override the
stack-protector functions from libc because statically linked functions
will take precedence. The end result, the app will always use the
"global" mode stack protector even if it's multithreaded. There may be a
way to make those functions private to liburing only, but I don't know.

We had a similar problem with memset() in liburing:

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/liburing.git/commit/?id=db5403e58083bef48d72656d7dea53a9f7affef4

Also, the app has to be compiled with those specific flags, which is out
of our control. Plus, I wonder if there is a chance to call
__stack_chk_init() from a static library point of view where we don't
control the entry point (__start).

Therefore, I won't implement the stack protector for liburing under
CONFIG_NOLIBC enabled. So far, I see that using the stack protector for
liburing nolibc is more trouble than it's worth.

But anyway, it's nice to see your stack protector work.

Regards,
-- 
Ammar Faizi


  reply	other threads:[~2023-06-22 22:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 17:20 [RFC PATCH liburing v1 0/3] Introduce '--use-libc' option Ammar Faizi
2023-06-22 17:20 ` [RFC PATCH liburing v1 1/3] configure: Remove --nolibc option Ammar Faizi
2023-06-22 17:20 ` [RFC PATCH liburing v1 2/3] configure: Introduce '--use-libc' option Ammar Faizi
2023-06-22 17:20 ` [RFC PATCH liburing v1 3/3] src/Makefile: Allow using stack protector with libc Ammar Faizi
2023-06-22 17:57   ` Thomas Weißschuh
2023-06-22 22:49     ` Ammar Faizi [this message]
2023-06-23 22:13 ` [RFC PATCH liburing v1 0/3] Introduce '--use-libc' option Jens Axboe

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=ZJTQDaAsN/[email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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