public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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

  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).