From: Florian Weimer <fweimer@redhat.com>
To: Siddhesh Poyarekar <siddhesh@sourceware.org>, libc-alpha@sourceware.org
Cc: carlos@redhat.com, adhemerval.zanella@linaro.org
Subject: Re: [PATCH 1/4] Add framework for tunables
Date: Tue, 27 Dec 2016 11:08:00 -0000 [thread overview]
Message-ID: <37ef7178-e83c-8318-4983-acfb3f422562@redhat.com> (raw)
In-Reply-To: <1479285306-11684-2-git-send-email-siddhesh@sourceware.org>
On 11/16/2016 09:35 AM, Siddhesh Poyarekar wrote:
> diff --git a/README.tunables b/README.tunables
> +The tunable framework allows modules within glibc to register variables that
> +may be tweaked through an environment variable or an API call. It aims to
This seems outdated, change with an API call is no longer supported.
> +enforce a strict namespace rule to bring consistency to naming of these tunable
> +environment variables across the project. This document is a guide for glibc
> +developers to add tunables to the framework.
> +
> +ADDING A NEW TUNABLE
> +--------------------
> +
> +The TOP_NAMESPACE is defined by default as 'glibc' and it may be overridden in
“The TOP_NAMESPACE macro”?
It's not clear based on this description if distributions are supposed
to change the default definition for glibc as a whole (I don't think
so), or where they are supposed to override the macro.
> diff --git a/csu/libc-start.c b/csu/libc-start.c
> index 99c040a..4e5cafa 100644
> --- a/csu/libc-start.c
> +++ b/csu/libc-start.c
> @@ -21,6 +21,11 @@
> #include <unistd.h>
> #include <ldsodefs.h>
> #include <exit-thread.h>
> +#include <libc-internal.h>
> +
> +#if HAVE_TUNABLES
> +# include <elf/dl-tunables.h>
> +#endif
I'd prefer if you could cut down the number of HAVE_TUNABLES conditionals.
> + /* Initialize very early so that tunables can use it. */
> + __libc_init_secure ();
> +
> +#if HAVE_TUNABLES
> + __tunables_init (__environ);
> +#endif
For !HAVE_TUNABLES, __tunables_init could be defined an empty inline
function, so that no code is generated for it.
> diff --git a/elf/dl-tunable-types.h b/elf/dl-tunable-types.h
> +#ifndef _TUNABLE_TYPES_H_
> +# define _TUNABLE_TYPES_H_
No indentation here.
> diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c
> new file mode 100644
> index 0000000..91340b6
> --- /dev/null
> +++ b/elf/dl-tunables.c
> @@ -0,0 +1,310 @@
> +/* The tunable framework. See the README to know how to use the tunable in
Should be “README.tunables”.
Parts of this file should probably go into csu/ because the code runs so
early during library startup (see my other comments).
> +static int
> +tunables_unsetenv (char **ep, const char *name)
This is copied from elf/dl-environ.c, it seems. Is it possible to avoid
creating this copy?
Calling either form of unsetenv is problematic because it may make the
auxiliary vector unreachable on !LIBC_START_MAIN_AUXVEC_ARG platforms
(which seems to include the majority, so perhaps this is a non-issue).
> +/* If the value does not validate, don't bother initializing the internal type
> + and also take care to clear the recorded string value in STRVAL. */
> +#define RETURN_IF_INVALID_RANGE(__cur, __val) \
> +({ \
> + __typeof ((__cur)->type.min) min = (__cur)->type.min; \
> + __typeof ((__cur)->type.max) max = (__cur)->type.max; \
> + if (min != max && ((__val) < min || (__val) > max)) \
> + return; \
> +})
Is it really necessary to turn this into a macro instead of an (inline)
function? The return statement could very well be located in the
caller, IMHO.
> +/* Disable a tunable if it is set. */
> +static void
> +disable_tunable (tunable_id_t id, char **envp)
> +{
> + const char *env_alias = tunable_list[id].env_alias;
> +
> + if (env_alias)
> + tunables_unsetenv (envp, tunable_list[id].env_alias);
> +}
env_alias != NULL.
> + default:
> + __builtin_unreachable ();
Should this rather be __bultin_trap?
> diff --git a/elf/dl-tunables.h b/elf/dl-tunables.h
> +/* A tunable. */
> +struct _tunable
> +{
> + const char *env_alias; /* The compatibility environment
> + variable name. */
Maybe store the variable name as well, as to
> +/* Same as TUNABLE_SET_VAL, but also set the callback function to __CB and call
> + it. */
> +# define TUNABLE_SET_VAL_WITH_CALLBACK(__id,__val,__cb) \
Comment seems misleading, the callback function isn't really set.
> diff --git a/elf/rtld.c b/elf/rtld.c
> index 647661c..eb211a2 100644
> --- a/elf/rtld.c
> +++ b/elf/rtld.c
> @@ -2527,11 +2527,13 @@ process_envvars (enum mode *modep)
> }
> while (*nextp != '\0');
>
> +#if !HAVE_TUNABLES
> if (__access ("/etc/suid-debug", F_OK) != 0)
> {
> unsetenv ("MALLOC_CHECK_");
> GLRO(dl_debug_mask) = 0;
> }
> +#endif
I believe this introduces a security vulnerability. You must keep the
setting of dl_debug_mask.
Thanks,
Florian
next prev parent reply other threads:[~2016-12-27 11:08 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 8:35 [PATCHv6 0/4] glibc tunables Siddhesh Poyarekar
2016-11-16 8:35 ` [PATCH 1/4] Add framework for tunables Siddhesh Poyarekar
2016-12-27 11:08 ` Florian Weimer [this message]
2016-12-27 20:59 ` Siddhesh Poyarekar
2016-12-27 21:12 ` Florian Weimer
2016-12-27 21:25 ` Siddhesh Poyarekar
2016-12-30 13:28 ` Joseph Myers
2016-12-31 13:48 ` Siddhesh Poyarekar
2016-11-16 8:35 ` [PATCH 3/4] Enhance --enable-tunables to select tunables frontend at build time Siddhesh Poyarekar
2016-12-27 11:44 ` Florian Weimer
2016-12-27 21:10 ` Siddhesh Poyarekar
2016-12-27 21:16 ` Florian Weimer
2016-11-16 8:35 ` [PATCH 4/4] User manual documentation for tunables Siddhesh Poyarekar
2016-11-16 13:49 ` Rical Jasan
2016-11-21 3:07 ` Siddhesh Poyarekar
2016-11-16 8:35 ` [PATCH 2/4] Initialize tunable list with the GLIBC_TUNABLES environment variable Siddhesh Poyarekar
2016-12-27 11:41 ` Florian Weimer
2016-12-27 21:35 ` Siddhesh Poyarekar
2016-11-21 2:58 ` [ping][PATCHv6 0/4] glibc tunables Siddhesh Poyarekar
2016-11-24 13:31 ` [PING 2][PATCHv6 " Siddhesh Poyarekar
2016-11-28 11:52 ` [PING 3][PATCHv6 " Siddhesh Poyarekar
2016-12-05 12:08 ` [PING 4][PATCHv6 " Siddhesh Poyarekar
2016-12-05 15:10 ` Steven Munroe
2016-12-12 16:20 ` [PING 5][PATCHv6 " Siddhesh Poyarekar
2016-12-26 14:29 ` [PING 6][PATCHv6 " Siddhesh Poyarekar
2016-12-27 9:49 ` [PATCHv6 " Florian Weimer
2016-12-30 4:09 [PATCH v7 " Siddhesh Poyarekar
2016-12-30 4:09 ` [PATCH 1/4] Add framework for tunables Siddhesh Poyarekar
2017-02-06 22:36 ` Andreas Schwab
2017-02-07 6:49 ` Siddhesh Poyarekar
2017-02-07 16:06 ` Andreas Schwab
2017-02-08 8:48 ` Siddhesh Poyarekar
2017-02-06 22:59 ` Andreas Schwab
2016-12-31 15:41 [PATCH v8 0/4] glibc tunables Siddhesh Poyarekar
[not found] ` <1483198831-2232-2-git-send-email-siddhesh@sourceware.org>
2016-12-31 16:49 ` [PATCH 1/4] Add framework for tunables Florian Weimer
2016-12-31 17:58 ` Siddhesh Poyarekar
2016-12-31 19:43 ` Florian Weimer
2016-12-31 19:50 ` Siddhesh Poyarekar
2016-12-31 19:52 ` Florian Weimer
2017-01-01 13:40 ` Nix
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=37ef7178-e83c-8318-4983-acfb3f422562@redhat.com \
--to=fweimer@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=siddhesh@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).