glibc/manual
Siddhesh Poyarekar 9bcd12d223 wcrtomb: Make behavior POSIX compliant
The GNU implementation of wcrtomb assumes that there are at least
MB_CUR_MAX bytes available in the destination buffer passed to wcrtomb
as the first argument.  This is not compatible with the POSIX
definition, which only requires enough space for the input wide
character.

This does not break much in practice because when users supply buffers
smaller than MB_CUR_MAX (e.g. in ncurses), they compute and dynamically
allocate the buffer, which results in enough spare space (thanks to
usable_size in malloc and padding in alloca) that no actual buffer
overflow occurs.  However when the code is built with _FORTIFY_SOURCE,
it runs into the hard check against MB_CUR_MAX in __wcrtomb_chk and
hence fails.  It wasn't evident until now since dynamic allocations
would result in wcrtomb not being fortified but since _FORTIFY_SOURCE=3,
that limitation is gone, resulting in such code failing.

To fix this problem, introduce an internal buffer that is MB_LEN_MAX
long and use that to perform the conversion and then copy the resultant
bytes into the destination buffer.  Also move the fortification check
into the main implementation, which checks the result after conversion
and aborts if the resultant byte count is greater than the destination
buffer size.

One complication is that applications that assume the MB_CUR_MAX
limitation to be gone may not be able to run safely on older glibcs if
they use static destination buffers smaller than MB_CUR_MAX; dynamic
allocations will always have enough spare space that no actual overruns
will occur.  One alternative to fixing this is to bump symbol version to
prevent them from running on older glibcs but that seems too strict a
constraint.  Instead, since these users will only have made this
decision on reading the manual, I have put a note in the manual warning
them about the pitfalls of having static buffers smaller than
MB_CUR_MAX and running them on older glibc.

Benchmarking:

The wcrtomb microbenchmark shows significant increases in maximum
execution time for all locales, ranging from 10x for ar_SA.UTF-8 to
1.5x-2x for nearly everything else.  The mean execution time however saw
practically no impact, with some results even being quicker, indicating
that cache locality has a much bigger role in the overhead.

Given that the additional copy uses a temporary buffer inside wcrtomb,
it's likely that a hot path will end up putting that buffer (which is
responsible for the additional overhead) in a similar place on stack,
giving the necessary cache locality to negate the overhead.  However in
situations where wcrtomb ends up getting called at wildly different
spots on the call stack (or is on different call stacks, e.g. with
threads or different execution contexts) and is still a hotspot, the
performance lag will be visible.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2022-05-13 19:15:46 +05:30
..
examples Update copyright dates with scripts/update-copyrights 2022-01-01 11:40:24 -08:00
argp.texi
arith.texi Add fmaximum, fminimum functions 2021-09-28 23:31:35 +00:00
charset.texi wcrtomb: Make behavior POSIX compliant 2022-05-13 19:15:46 +05:30
check-safety.sh Update copyright dates with scripts/update-copyrights 2022-01-01 11:40:24 -08:00
conf.texi
contrib.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
creature.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
crypt.texi
ctype.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
debug.texi
dir
dynlink.texi dlfcn: Implement the RTLD_DI_PHDR request type for dlinfo 2022-04-29 17:00:53 +02:00
errno.texi hurd: Define ELIBEXEC 2022-04-12 22:16:40 +02:00
fdl-1.3.texi
filesys.texi
freemanuals.texi
getopt.texi manual: Clarify that abbreviations of long options are allowed 2022-05-04 15:56:47 +05:30
header.texi
install-plain.texi
install.texi INSTALL: Rephrase -with-default-link documentation 2022-04-26 14:22:23 +02:00
intro.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
io.texi
ipc.texi
job.texi
lang.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
lgpl-2.1.texi
libc-texinfo.sh
libc.texinfo Update copyright dates with scripts/update-copyrights 2022-01-01 11:40:24 -08:00
libcbook.texi
llio.texi llio.texi: Wording fixes in description of closefrom() 2021-08-26 15:23:07 -03:00
locale.texi
macros.texi
maint.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
Makefile Update copyright dates with scripts/update-copyrights 2022-01-01 11:40:24 -08:00
math.texi x86_64: Document libmvec vector functions accuracy [BZ #28766] 2022-01-19 07:57:11 -08:00
memory.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
message.texi
nss.texi nss: Use "files dns" as the default for the hosts database (bug 28700) 2021-12-17 12:01:25 +01:00
nsswitch.texi
pattern.texi
pipe.texi
platform.texi x86: Install <bits/platform/x86.h> [BZ #27958] 2021-07-23 05:12:51 -07:00
probes.texi elf: Add _dl_find_object function 2021-12-28 22:52:56 +01:00
process.texi nptl: Handle spurious EINTR when thread cancellation is disabled (BZ#29029) 2022-04-14 12:48:31 -03:00
README.pretty-printers
README.tunables
resource.texi
search.texi
setjmp.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
signal.texi manual: SA_ONSTACK is ignored without alternate stack 2022-02-28 11:50:41 +01:00
socket.texi
startup.texi
stdio-fp.c
stdio.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
string.texi manual: Drop obsolete @refill 2022-01-12 14:28:44 +05:30
summary.pl Update copyright dates with scripts/update-copyrights 2022-01-01 11:40:24 -08:00
sysinfo.texi
syslog.texi
terminal.texi
texinfo.tex
texis.awk
threads.texi Linux: Use ptrdiff_t for __rseq_offset 2022-02-02 22:37:20 +01:00
time.texi
tsort.awk Update copyright dates with scripts/update-copyrights 2022-01-01 11:40:24 -08:00
tunables.texi malloc: Add Huge Page support for mmap 2021-12-15 17:35:38 -03:00
users.texi
xtract-typefun.awk

			TUNABLE FRAMEWORK
			=================

Tunables is a feature in the GNU C Library that allows application authors and
distribution maintainers to alter the runtime library behaviour to match their
workload.

The tunable framework allows modules within glibc to register variables that
may be tweaked through an environment variable.  It aims to 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 macro is defined by default as 'glibc'.  If distributions
intend to add their own tunables, they should do so in a different top
namespace by overriding the TOP_NAMESPACE macro for that tunable.  Downstream
implementations are discouraged from using the 'glibc' top namespace for
tunables they don't already have consensus to push upstream.

There are three steps to adding a tunable:

1. Add a tunable to the list and fully specify its properties:

For each tunable you want to add, make an entry in elf/dl-tunables.list.  The
format of the file is as follows:

TOP_NAMESPACE {
  NAMESPACE1 {
    TUNABLE1 {
      # tunable attributes, one per line
    }
    # A tunable with default attributes, i.e. string variable.
    TUNABLE2
    TUNABLE3 {
      # its attributes
    }
  }
  NAMESPACE2 {
    ...
  }
}

The list of allowed attributes are:

- type:			Data type.  Defaults to STRING.  Allowed types are:
			INT_32, UINT_64, SIZE_T and STRING.  Numeric types may
			be in octal or hexadecimal format too.

- minval:		Optional minimum acceptable value.  For a string type
			this is the minimum length of the value.

- maxval:		Optional maximum acceptable value.  For a string type
			this is the maximum length of the value.

- default:		Specify an optional default value for the tunable.

- env_alias:		An alias environment variable

- security_level:	Specify security level of the tunable for AT_SECURE
			binaries.  Valid values are:

			SXID_ERASE: (default) Do not read and do not pass on to
			child processes.
			SXID_IGNORE: Do not read, but retain for non-AT_SECURE
			child processes.
			NONE: Read all the time.

2. Use TUNABLE_GET/TUNABLE_SET/TUNABLE_SET_WITH_BOUNDS to get and set tunables.

3. OPTIONAL: If tunables in a namespace are being used multiple times within a
   specific module, set the TUNABLE_NAMESPACE macro to reduce the amount of
   typing.

GETTING AND SETTING TUNABLES
----------------------------

When the TUNABLE_NAMESPACE macro is defined, one may get tunables in that
module using the TUNABLE_GET macro as follows:

  val = TUNABLE_GET (check, int32_t, TUNABLE_CALLBACK (check_callback))

where 'check' is the tunable name, 'int32_t' is the C type of the tunable and
'check_callback' is the function to call if the tunable got initialized to a
non-default value.  The macro returns the value as type 'int32_t'.

The callback function should be defined as follows:

  void
  TUNABLE_CALLBACK (check_callback) (int32_t *valp)
  {
  ...
  }

where it can expect the tunable value to be passed in VALP.

Tunables in the module can be updated using:

  TUNABLE_SET (check, val)

where 'check' is the tunable name and 'val' is a value of same type.

To get and set tunables in a different namespace from that module, use the full
form of the macros as follows:

  val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL)

  TUNABLE_SET_FULL (glibc, cpu, hwcap_mask, val)

where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the
remaining arguments are the same as the short form macros.

The minimum and maximum values can updated together with the tunable value
using:

  TUNABLE_SET_WITH_BOUNDS (check, val, min, max)

where 'check' is the tunable name, 'val' is a value of same type, 'min' and
'max' are the minimum and maximum values of the tunable.

To set the minimum and maximum values of tunables in a different namespace
from that module, use the full form of the macros as follows:

  val = TUNABLE_GET_FULL (glibc, cpu, hwcap_mask, uint64_t, NULL)

  TUNABLE_SET_WITH_BOUNDS_FULL (glibc, cpu, hwcap_mask, val, min, max)

where 'glibc' is the top namespace, 'cpu' is the tunable namespace and the
remaining arguments are the same as the short form macros.

When TUNABLE_NAMESPACE is not defined in a module, TUNABLE_GET is equivalent to
TUNABLE_GET_FULL, so you will need to provide full namespace information for
both macros.  Likewise for TUNABLE_SET, TUNABLE_SET_FULL,
TUNABLE_SET_WITH_BOUNDS and TUNABLE_SET_WITH_BOUNDS_FULL.

** IMPORTANT NOTE **

The tunable list is set as read-only after the dynamic linker relocates itself,
so setting tunable values must be limited only to tunables within the dynamic
linker, that too before relocation.

FUTURE WORK
-----------

The framework currently only allows a one-time initialization of variables
through environment variables and in some cases, modification of variables via
an API call.  A future goals for this project include:

- Setting system-wide and user-wide defaults for tunables through some
  mechanism like a configuration file.

- Allow tweaking of some tunables at runtime