From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6920 Path: news.gmane.org!not-for-mail From: Nathan McSween Newsgroups: gmane.linux.lib.musl.general Subject: Re: thoughts on reallocarray, explicit_bzero? Date: Wed, 28 Jan 2015 14:38:06 -0800 Message-ID: References: <20140519153130.GA519@muslin> <20140519161654.GO507@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd91f466e4f8a050dbe0655 X-Trace: ger.gmane.org 1422484703 5230 80.91.229.3 (28 Jan 2015 22:38:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 22:38:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6933-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 28 23:38:23 2015 Return-path: 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 ) id 1YGbFb-00026e-9J for gllmg-musl@m.gmane.org; Wed, 28 Jan 2015 23:38:19 +0100 Original-Received: (qmail 23990 invoked by uid 550); 28 Jan 2015 22:38:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23980 invoked from network); 28 Jan 2015 22:38:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zeO9k5kJ+GWo6/dwOZG9Hs/VgWU2DGV1ON7MhRPa/4g=; b=s3gAT+kbzXBy3ivEQkA8IDC2ab1DOR+gGyQkwK2lxkksUB9iKKO4ysynBmCyUfA2aM Q7A+dcjBiaq7fphzReM9NgsvoI/WHt+RfknRvXVUvSmyP/kN8SwP1xZv5z6j1oxxz2ko WMvlkViu8yyu4d++mKN8PKdMaw7fdbBz4DMQnkR4HBKHMriy4oNz9C7zIh6dHn6/QBDQ MAHEMrUm9b+UTBpktxawBvesPVSr4ftOsaOo21s0PRtUsq3C/pdvt9/VHyrirpbGqF1n W+8RnUWDZzW6NgYG8twONDsM/b+nvYVagO0ZjkJZbdpzGkLbfafx/u06tinHsV6as9KQ TIQA== X-Received: by 10.195.13.12 with SMTP id eu12mr12013486wjd.62.1422484686391; Wed, 28 Jan 2015 14:38:06 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:6920 Archived-At: --047d7bd91f466e4f8a050dbe0655 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How can a compiler optimize out a memory barrier? On Jan 28, 2015 2:34 PM, "Daniel Cegie=C5=82ka" wrote: > 2015-01-28 23:01 GMT+01:00 Daniel Cegie=C5=82ka : > > 2014-05-19 18:16 GMT+02:00 Rich Felker : > >> On Mon, May 19, 2014 at 05:44:59PM +0200, Daniel Cegie=C5=82ka wrote: > > > >>> diff -urN musl.orig/src/string/explicit_bzero.c > musl/src/string/explicit_bzero.c > >>> --- musl.orig/src/string/explicit_bzero.c Thu Jan 1 00:00:00 197= 0 > >>> +++ musl/src/string/explicit_bzero.c Fri May 9 09:57:45 2014 > >>> @@ -0,0 +1,8 @@ > >>> +#include > >>> + > >>> +static void *(*volatile explicit_memset)(void *, int, size_t) =3D > memset; > >>> + > >>> +void explicit_bzero(void *b, size_t len) > >>> +{ > >>> + (*explicit_memset)(b, 0, len); > >>> +} > >> > >> This is a nice trick, but IIRC I actually observed GCC optimizing out > >> similar code before (instead of your static volatile, I used a > >> volatile compound literal). At least the concept is right though: you > >> want to prevent the compiler from being able to do any flow analysis > >> at compile time, and making the function pointer volatile achieves > >> this rather well. On the other hand, GCC will put the volatile pointer > >> (if it even emits it) in non-constant memory, meaning it's an > >> additional attack vector for function-pointer-overwrite attacks. > > > > Linux kernel has similar functions and uses a barrier() here: > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/= string.c?id=3Drefs/tags/v3.19-rc6#n600 > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/incl= ude/linux/compiler.h?id=3Drefs/tags/v3.19-rc6#n162 > > > > Is such a solution is more correct (and still portable)? > > I'm afraid that the only appropriate solution is to use memset_s() > from C11 and the expectation that the compiler will accept it. > barrier() does not give any guarantee that this function will be > secure. Only compiler decides. I'm afraid that OpenBSD goes bad path > with explicit_bzero(). The same applies to the linux kernel and > memzero_explicit().. very stupid name... > > Daniel > --047d7bd91f466e4f8a050dbe0655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

How can a compiler optimize out a memory barrier?

On Jan 28, 2015 2:34 PM, "Daniel Cegie=C5= =82ka" <daniel.cegielk= a@gmail.com> wrote:
2015-01-28 23:01 GMT+01:00 Daniel Cegie=C5=82ka <daniel.cegielka@gmail.com>:
> 2014-05-19 18:16 GMT+02:00 Rich Felker <dalias@libc.org>:
>> On Mon, May 19, 2014 at 05:44:59PM +0200, Daniel Cegie=C5=82ka wro= te:
>
>>> diff -urN musl.orig/src/string/explicit_bzero.c musl/src/strin= g/explicit_bzero.c
>>> --- musl.orig/src/string/explicit_bzero.c=C2=A0 =C2=A0 =C2=A0T= hu Jan=C2=A0 1 00:00:00 1970
>>> +++ musl/src/string/explicit_bzero.c=C2=A0 Fri May=C2=A0 9 09:= 57:45 2014
>>> @@ -0,0 +1,8 @@
>>> +#include <string.h>
>>> +
>>> +static void *(*volatile explicit_memset)(void *, int, size_t)= =3D memset;
>>> +
>>> +void explicit_bzero(void *b, size_t len)
>>> +{
>>> +=C2=A0 =C2=A0 =C2=A0(*explicit_memset)(b, 0, len);
>>> +}
>>
>> This is a nice trick, but IIRC I actually observed GCC optimizing = out
>> similar code before (instead of your static volatile, I used a
>> volatile compound literal). At least the concept is right though: = you
>> want to prevent the compiler from being able to do any flow analys= is
>> at compile time, and making the function pointer volatile achieves=
>> this rather well. On the other hand, GCC will put the volatile poi= nter
>> (if it even emits it) in non-constant memory, meaning it's an<= br> >> additional attack vector for function-pointer-overwrite attacks. >
> Linux kernel has similar functions and uses a barrier() here:
>
> htt= ps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/lib/strin= g.c?id=3Drefs/tags/v3.19-rc6#n600
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tr= ee/include/linux/compiler.h?id=3Drefs/tags/v3.19-rc6#n162
>
> Is such a solution is more correct (and still portable)?

I'm afraid that the only appropriate solution is to use memset_s()
from C11 and the expectation that the compiler will accept it.
barrier() does not give any guarantee that this function will be
secure. Only compiler decides. I'm afraid that OpenBSD goes bad path with explicit_bzero(). The same applies to the linux kernel and
memzero_explicit().. very stupid name...

Daniel
--047d7bd91f466e4f8a050dbe0655--