Differential D10161 Diff 26761 lib/libc/stdlib/set_constraint_handler_s.c

Changeset View

Standalone View

lib/libc/stdlib/set_constraint_handler_s.c

This file was added.

				/*-
				* Copyright (c) 2017 Juniper Networks. All rights reserved.
				*
				* Redistribution and use in source and binary forms, with or without
				* modification, are permitted provided that the following conditions
				* are met:
				* 1. Redistributions of source code must retain the above copyright
				* notice, this list of conditions and the following disclaimer.
				* 2. Redistributions in binary form must reproduce the above copyright
				* notice, this list of conditions and the following disclaimer in the
				* documentation and/or other materials provided with the distribution.
				*
				* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
				* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
				* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
				* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
				* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
				* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
				* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
				* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
				* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
				* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
				* SUCH DAMAGE.
				*/

				#include <sys/cdefs.h>
				__FBSDID("$FreeBSD$");

				#include "namespace.h"
				#include <sys/types.h>
				#include <machine/atomic.h>
				#include <errno.h>
				#include <pthread.h>
				#include <stddef.h>
				#include <stdlib.h>
				#include "un-namespace.h"
				#include "libc_private.h"

				/*
				* Rationale recommends allocating new memory each time. Memory
				* cannot be freed without risking __throw_constraint_handler_s
				* accessing free memory.
				*/
				static constraint_handler_t *_ch = NULL;
				static pthread_mutex_t ch_lock = PTHREAD_MUTEX_INITIALIZER;

				constraint_handler_t
				set_constraint_handler_s(constraint_handler_t handler)
				{
				constraint_handler_t new, old, ret;

				new = malloc(sizeof(constraint_handler_t));
				if (new == NULL)
				return (NULL);
				*new = handler;
				if (__isthreaded)
				_pthread_mutex_lock(&ch_lock);
				old = _ch;
				_ch = new;
				trix_juniper.netUnsubmitted Not Done Inline Actions A memory leak, need to free old. trix_juniper.net: A memory leak, need to free old.
				kibAuthorUnsubmitted Not Done Inline Actions Well, I cannot free the memory there, see the updated comment above the definition of '_ch'. If going into this direction, either memory should not be allocated (could you, please, point to the rationale text ?) or lock used instead of lockless algorithm. I thought that the set interface is used rarely so that the leak is not important. kib: Well, I cannot free the memory there, see the updated comment above the definition of '_ch'.
				trix_juniper.netUnsubmitted Not Done Inline Actions Instead of atomics, a mutex would work. Here is the rationale from n1173 Most implementations will probably use a pointer to function in their implementation of the set_constraint_handler_s function to hold the address of the currently registered handler. Unfortunately, pointers to functions are employed by many security exploits. If an exploit deposits new code into a program, the exploit must find a way to cause that new code to be executed. The most common way is to alter the return address on the stack to point to the new code, but an alternative is to find a pointer to a function, and store the address of the new code in that pointer. The committee thought that the benefit of a user-settable runtime-constraint handler justified providing another pointer to function that might be exploited. There are steps that an implementation can take to mitigate the vulnerability of the pointer. Some possibilities are: • Dynamically allocate the pointer or otherwise arrange for the address of the pointer to change every time the program runs • Write-protect the page containing the pointer, and have set_constraint_handler_s only write-enable the storage when it is updating the pointer’s value. • “Encode” the value of the pointer, so that it is not a pure address. trix_juniper.net: Instead of atomics, a mutex would work. Here is the rationale from n1173 Most implementations…
				if (__isthreaded)
				_pthread_mutex_unlock(&ch_lock);
				if (old == NULL) {
				ret = NULL;
				} else {
				ret = *old;
				free(old);
				}
				return (ret);
				}

				void
				__throw_constraint_handler_s(const char * restrict msg, errno_t error)
				{
				constraint_handler_t ch;

				if (__isthreaded)
				_pthread_mutex_lock(&ch_lock);
				ch = _ch != NULL ? *_ch : NULL;
				if (__isthreaded)
				_pthread_mutex_unlock(&ch_lock);
				if (ch != NULL)
				ch(msg, NULL, error);
				}

				void
				abort_handler_s(const char * restrict msg __unused,
				void * restrict ptr __unused, errno_t error __unused)
				{

				abort();
				}

				void
				ignore_handler_s(const char * restrict msg __unused,
				void * restrict ptr __unused, errno_t error __unused)
				{
				}