From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 361D21396D9 for ; Mon, 13 Nov 2017 11:39:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05FF8E11BD; Mon, 13 Nov 2017 11:38:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AA69DE1179 for ; Mon, 13 Nov 2017 11:38:56 +0000 (UTC) Received: from [192.168.2.51] (85.253.86.194.cable.starman.ee [85.253.86.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: leio) by smtp.gentoo.org (Postfix) with ESMTPSA id 042A833BEB4 for ; Mon, 13 Nov 2017 11:38:54 +0000 (UTC) Message-ID: <1510573131.5906.2.camel@gentoo.org> Subject: Re: [gentoo-user] Re: memset_s From: Mart Raudsepp To: gentoo-user@lists.gentoo.org Date: Mon, 13 Nov 2017 13:38:51 +0200 In-Reply-To: References: <26501197.ioODuGg76y@thetick> <1510542223.24203.0.camel@gentoo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 21d1d304-c043-42b9-9a6a-03bd799f5e3e X-Archives-Hash: 4f052ab7026c97b7737371f7b79d80df On E, 2017-11-13 at 12:44 +0200, Nikos Chantziaras wrote: > On 13/11/17 09:17, Jorge Almeida wrote: > > > > On Sun, Nov 12, 2017 at 7:03 PM, Mart Raudsepp > > wrote: > > > > > > On L, 2017-11-11 at 00:10 +0000, Jorge Almeida wrote: > > > > > > > > Well, most programmers probably won't care about this stuff > > > > anyway, > > > > and people who deal with cryptography tend to be more cautious > > > > than > > > > average. But I'm not really making a case for safe versions of > > > > known > > > > functions. After all, the usual functions do fine for most > > > > applications. memset() would be enough to clear RAM with > > > > sensitive > > > > data if we had a pragma (or equivalent) to convince the > > > > compiler to > > > > not ignore it (I mean a pragma to invoke on a particular > > > > function > > > > definition when the programmer  feels that a black box > > > > behaviour is > > > > undesirable). Of course, solving the problem of the compiler > > > > copying > > > > stuff around might be harder nut to crack. > > > Sounds like you want explicit_bzero from libbsd? > > > > > According to their man page, yes. I'll have to [try to] check the > > source. I wonder how they do it? Even the volatile modifier doesn't > > solve the problem, according to the link in previous post. > explicit_bzero() is available in glibc. It's in . Interesting. Some Xorg stuff is using libbsd explicitly, but probably since before glibc gained this. This is new since glibc-2.25. How they do it you can find out from the source code. In libbsd case, I saw a weak linked (do-nothing) function call after memset, so the compiler can't know if that weakly linked function isn't getting replaced with something that might do something with the zeroed memory, and thus can't optimize it out. Though I looked at an older libbsd.