From: Stefan Hajnoczi <stefanha@redhat.com>
To: Ammar Faizi <ammarfaizi2@gnuweeb.org>
Cc: io-uring@vger.kernel.org,
Ammar Faizi <ammar.faizi@students.amikom.ac.id>,
Jens Axboe <axboe@kernel.dk>, Jeff Moyer <jmoyer@redhat.com>,
Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>,
Guillem Jover <guillem@hadrons.org>
Subject: Re: False positives in nolibc check
Date: Wed, 21 Jun 2023 12:04:47 +0200 [thread overview]
Message-ID: <20230621100447.GD2667602@fedora> (raw)
In-Reply-To: <ZJHKdAf2tPe+6BS6@biznet-home.integral.gnuweeb.org>
[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]
On Tue, Jun 20, 2023 at 10:49:08PM +0700, Ammar Faizi wrote:
> On Tue, Jun 20, 2023 at 03:31:52PM +0200, Stefan Hajnoczi wrote:
> > This is caused by the stack protector compiler options, which depend on
> > the libc __stack_chk_fail_local symbol.
>
> Guillem fixed it last week. Does this commit fix the stack protector
> problem? https://github.com/axboe/liburing/commit/319f4be8bd049055c333185928758d0fb445fc43
>
> > In general, I'm concerned that nolibc is fragile because the toolchain
> > and libc sometimes have dependencies that are activated by certain
> > compiler options. Some users will want libc and others will not. Maybe
> > make it an explicit option instead of probing?
>
> I made nolibc always enabled because I don't see the need of using libc
> in liburing. If we have a real reason of using libc, maybe adding
> '--use-libc' is better than bringing back '--nolibc'.
>
> I agree with what Alviro said that using stack protector in liburing is
> too overkill. That's why I see no reason for the upstream to support it.
>
> Can you mention other dependencies that do need libc? That information
> would be useful to consider bringing back libc to liburing.
I don't know which features require the toolchain and libc to cooperate.
I guess Thread Local Storage won't work and helper functions that
compilers emit (like the memset example that Alviro gave).
Disabling hardening because it requires work to support it in a nolibc
world seems dubious to me. I don't think it's a good idea for io_uring
to lower security because that hurts its image and reduces adoption.
Especially right now, when the security of io_uring is being scrutinized
(https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html).
While I'm sharing these opinions with you, I understand that some people
want nolibc and are fine with disabling the stack protector. The main
thing I would like is for liburing to compile or fail with a clear error
message instead of breaking somewhere during the build.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-06-21 10:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 13:31 False positives in nolibc check Stefan Hajnoczi
2023-06-20 14:39 ` Alviro Iskandar Setiawan
2023-06-21 9:47 ` Stefan Hajnoczi
2023-06-20 15:49 ` Ammar Faizi
2023-06-20 16:16 ` Alviro Iskandar Setiawan
2023-06-21 10:04 ` Stefan Hajnoczi [this message]
2023-06-21 10:19 ` Ammar Faizi
2023-06-21 11:51 ` Guillem Jover
2023-06-21 16:08 ` Ammar Faizi
2023-07-12 15:00 ` Stefan Hajnoczi
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=20230621100447.GD2667602@fedora \
--to=stefanha@redhat.com \
--cc=alviro.iskandar@gnuweeb.org \
--cc=ammar.faizi@students.amikom.ac.id \
--cc=ammarfaizi2@gnuweeb.org \
--cc=axboe@kernel.dk \
--cc=guillem@hadrons.org \
--cc=io-uring@vger.kernel.org \
--cc=jmoyer@redhat.com \
/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 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.