public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
	libc-alpha@sourceware.org, Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH 0/2] Make tunable a default feature
Date: Mon, 20 Mar 2023 19:15:41 -0400	[thread overview]
Message-ID: <9a6d86db-e799-0476-98cf-253a533d12ad@gotplt.org> (raw)
In-Reply-To: <fbfbbf25-6086-309e-bdf1-56d06387c610@linaro.org>

On 2023-03-20 12:59, Adhemerval Zanella Netto wrote:
> I think it might make sense for tunables that change the program semantic, such
> as security hardening; although I don't think it really fits for performance
> oriented ones (such malloc or pthread tuning).  So maybe we can define a global

Administrative level performance tuning defaults for setuid binaries?

> file format where the administrator can set where setuid binaries can use it,
> and if uses can overwrite it.  My initial idea would be something quite simple,
> similar to sysctl.conf:

Yes, I think Florian suggested reusing ld.so.conf instead.  I don't have 
a strong preference either way so y'all can fight that one out - potato 
potato ;)

> And I was thinking about an DF_1_NODEFLIB analogous so the program can opt-out
> any performance or behavior difference any tunable might incur.  Although with
> your idea of enforceable tunable, I think it does not make much sense.

Yeah an ELF flag to override all tunables seems counter to the whole 
idea, but ELF flags to override specific tunables may make sense.  E.g. 
memory tagging enabled by default in the system and a program built with 
DF_NO_MEMTAG overrides that systemwide setting.

Sid

  reply	other threads:[~2023-03-20 23:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 19:06 Adhemerval Zanella
2023-03-13 19:06 ` [PATCH 1/2] elf: Remove glibc.rtld.dynamic_sort tunable Adhemerval Zanella
2023-03-22 17:08   ` Siddhesh Poyarekar
2023-03-22 17:51     ` Adhemerval Zanella Netto
2023-03-22 18:40       ` Siddhesh Poyarekar
2023-03-22 18:46         ` Adhemerval Zanella Netto
2023-03-22 18:52           ` Siddhesh Poyarekar
2023-03-22 19:11             ` Adhemerval Zanella Netto
2023-03-13 19:06 ` [PATCH 2/2] Remove --enable-tunables configure option Adhemerval Zanella
2023-03-22 16:25   ` Siddhesh Poyarekar
2023-03-14 18:02 ` [PATCH 0/2] Make tunable a default feature Siddhesh Poyarekar
2023-03-15 20:05   ` Adhemerval Zanella Netto
2023-03-17 11:15     ` Siddhesh Poyarekar
2023-03-20 16:59       ` Adhemerval Zanella Netto
2023-03-20 23:15         ` Siddhesh Poyarekar [this message]
2023-03-22 14:40           ` Adhemerval Zanella Netto
2023-03-22 15:21             ` Siddhesh Poyarekar
2023-03-22 17:58               ` Adhemerval Zanella Netto

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=9a6d86db-e799-0476-98cf-253a533d12ad@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).