From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6930
Path: news.gmane.org!not-for-mail
From: Szabolcs Nagy <nsz@port70.net>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: thoughts on reallocarray, explicit_bzero?
Date: Thu, 29 Jan 2015 11:04:31 +0100
Message-ID: <20150129100431.GJ32318@port70.net>
References: <20140519153130.GA519@muslin>
 <CAPLrYESpEg_yvyn0odnnr9=0Fg3Ussg7cHH=om1G_yvb8zsQ8Q@mail.gmail.com>
 <20140519161654.GO507@brightrain.aerifal.cx>
 <CAPLrYERjMhKWP4pQ6-b7SsNFXcQPaJkRHvspzvtUw3ezuj2ABw@mail.gmail.com>
 <CAPLrYETk3dT8EnCbqts1u3FYO=iPP7SBop2J_wixk87isR7PPQ@mail.gmail.com>
 <20150129021919.GM4574@brightrain.aerifal.cx>
 <CAPDERwo886JY55T9hokUeNiV9dHBxTmZaSTq82WBQun+pLqouw@mail.gmail.com>
 <20150129041509.GN4574@brightrain.aerifal.cx>
 <CAPLrYEQDw-afOSS+o4Z82LsZRaUyJn+x18d_qVO5BO13aV-GgA@mail.gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ger.gmane.org 1422525894 17910 80.91.229.3 (29 Jan 2015 10:04:54 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 29 Jan 2015 10:04:54 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-6943-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 29 11:04:46 2015
Return-path: <musl-return-6943-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@m.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-6943-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1YGlxt-0002hA-5e
	for gllmg-musl@m.gmane.org; Thu, 29 Jan 2015 11:04:45 +0100
Original-Received: (qmail 32681 invoked by uid 550); 29 Jan 2015 10:04:43 -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 32672 invoked from network); 29 Jan 2015 10:04:43 -0000
Mail-Followup-To: musl@lists.openwall.com
Content-Disposition: inline
In-Reply-To: <CAPLrYEQDw-afOSS+o4Z82LsZRaUyJn+x18d_qVO5BO13aV-GgA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Xref: news.gmane.org gmane.linux.lib.musl.general:6930
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/6930>

* Daniel Cegie??ka <daniel.cegielka@gmail.com> [2015-01-29 10:30:40 +0100]:
> yet another secure_memzero(). A better solution would be to promote a
> single standard (eg. memset_s()) and the expectation that the compiler
> will respect it.
> 

i think you don't know the semantics of memset_s
(it uses nonsense types, has superflous arguments, handles
constraint violations through global state etc)

it is a complicated mess and not a good api to standardize on
if all you want is to avoid information leak in crypto code

(btw no memset based solution can provide complete protection
against info leak: if the crypto function is interrupted by
a signal then all the register state will be copied to the
stack or altstack and kept around for arbitrarily long time
which is plenty information leaked)