From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5135
Path: news.gmane.org!not-for-mail
From: =?UTF-8?Q?Daniel_Cegie=C5=82ka?= <daniel.cegielka@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: thoughts on reallocarray, explicit_bzero?
Date: Mon, 19 May 2014 18:45:08 +0200
Message-ID: <CAPLrYERvsFF=0UN-gRchd7zY0ViKNf6QA5bt7Oj5mGcxpLzbdA@mail.gmail.com>
References: <20140519153130.GA519@muslin> <20140519162556.GY12324@port70.net>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Trace: ger.gmane.org 1400517949 2517 80.91.229.3 (19 May 2014 16:45:49 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 19 May 2014 16:45:49 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-5140-gllmg-musl=m.gmane.org@lists.openwall.com Mon May 19 18:45:42 2014
Return-path: <musl-return-5140-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@plane.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by plane.gmane.org with smtp (Exim 4.69)
	(envelope-from <musl-return-5140-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1WmQh4-0007Zl-1W
	for gllmg-musl@plane.gmane.org; Mon, 19 May 2014 18:45:42 +0200
Original-Received: (qmail 7468 invoked by uid 550); 19 May 2014 16:45:41 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 7460 invoked from network); 19 May 2014 16:45:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        bh=tFDT1uAtxciP9oTAbJZVY1tMY4y2PfXEVopHAojN7MY=;
        b=Wdbv7gGOu7r5mQLKZC+KZxvv0BiFU5+MImeK9WUvFQHEXNQlMd5FHv+MoMES4f/Wtg
         Xec17brepq4qVbwZjwU4NToRUUf9+tAlxodP3297cgZNhQT3fT2x8xXG14IWaH8nMmdg
         HGB8AVG1rkRtw0/LNdNYyvSS8MK6hiXR216dasL1LImDLf0FE2/E+Tu1Sy6z/wlJ1euB
         dlcP34TNeL7bsSR77K/QQoqnSOb9PADrQqLnn24sdTL1nKrXgQ7mbUv44DAPLyo7g4LM
         +ZLbJt5hk9lII2XIrltjgwcaJf3UQeM/zUqWsgy1XJRm9BlNeGm4tLvgVgHj7mXGyJyx
         w9eg==
X-Received: by 10.224.169.6 with SMTP id w6mr6631131qay.102.1400517929535;
 Mon, 19 May 2014 09:45:29 -0700 (PDT)
In-Reply-To: <20140519162556.GY12324@port70.net>
Xref: news.gmane.org gmane.linux.lib.musl.general:5135
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/5135>

2014-05-19 18:25 GMT+02:00 Szabolcs Nagy <nsz@port70.net>:

> i don't see how the openbsd explicit_bzero stops the
> compiler to do optimizations..
>
> (i guess they rely on that their gcc does not do lto
> or that libc is dynamic linked and the compiler has no
> 'explicit_bzero' builtin, neither of which is a great
> solution..)
>
> the usual approach to this is volatile function pointer:
>
> static void *(*volatile force_memset)(void,int,size_t) = memset;
>
> in general in c one cannot be sure that the secret bits
> are not leaked somewhere since the languge spec cannot
> give such guarantees
>
> that said either the volatile funcptr or actually reusing
> the memory such that it cannot be optimized away works in
> practice

first version:

void explicit_bzero(void * const b, const size_t l)
{
    volatile unsigned char *p = (volatile unsigned char *) b;
    size_t i = (size_t) 0U;

    while (i < l) {
        p[i++] = 0U;
    }
}

Of course, if someone has better ideas... I'm very curious :)

Daniel