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 E54DA1396D9 for ; Fri, 10 Nov 2017 23:19:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75FFDE0F92; Fri, 10 Nov 2017 23:19:33 +0000 (UTC) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 1B283E0F8C for ; Fri, 10 Nov 2017 23:19:32 +0000 (UTC) Received: by mail-yw0-x234.google.com with SMTP id c186so6794394ywb.2 for ; Fri, 10 Nov 2017 15:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WiITbIi5rpwqDAQHPfmcXGpz5g1V73G6dsQ30CFMBbY=; b=egLZ/SxtepROv5i3zl7CwpGOAi3Lp+1rz1PZOmMxf5st8c4C6gN7TflKL0PkKtyorO m38upkoN0wALaq9iErwFKE0xTSlJ2sDPA1v2TGxgLhNr8/QnuCAXIbO4pzq3RMKFnYF1 uaENMVANcdNjrzwag/FWLl7hFqis3gP2p5JKssY0yWzPdfHpVNFadjcPeGwDwbISMrSr cCFfslDqFOapIHXi1v2hXEW6TMWmKzo+unrCOkpm9sVbUdCZXS3BwmXiJcPicQheKV7v xEJKwHPaPUV5HFyn29LS2vUMGKBXKc+mUyESLd2v3GdqPutgU5DWXBAVhP0sN5BuArHZ Ix6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=WiITbIi5rpwqDAQHPfmcXGpz5g1V73G6dsQ30CFMBbY=; b=A3kCqutUPNL2bcEK4Cl7fy0FazqF5Cy10neF88TxWb/bNx0rNKes6Wob+36KxON1bO 3xqZeavja9oj84Vuu3DJnrY0egxdlJtdZKGu6CV2DMAAGH1OlBJb5p+IkeUx25phfO06 F3qGP7PP+ITE9g6BFbuaHb+QJ4Kz0OXAYlof9cLXIaqZ3n1DHVZAV492ZTsaf1/RChfe MAPjvWj3Hb1zESmR7mUes5JoUS0qVUF/wDLfXzUX9vIL5p3qP3SNRFbGFEA4UqAvvI9m orDOyIrR6VmsYIe7SCt8SWcC5n8ZxSOnVRVT8GyKDmpxk5kuSsbXUZZq9RGeanrSrA+1 IbZw== X-Gm-Message-State: AJaThX7ktRQS7D80nq722mD0dzEmJG2RI0TFddp4BoFGx4KVOi1etYNc T8YulQtcO58utVE12s+0kDEMlSPEYVMrpLKTvV4= X-Google-Smtp-Source: AGs4zMY4S6PNHl3NlQnmEk6BB5H1fwe1L5zoa9pdzcO0QKkI98qlam0XuDbK0XqXRzbXCvAgoEPkEXHUWonTf+PZJTo= X-Received: by 10.129.55.15 with SMTP id e15mr1366230ywa.221.1510355971793; Fri, 10 Nov 2017 15:19:31 -0800 (PST) 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 Received: by 10.129.49.7 with HTTP; Fri, 10 Nov 2017 15:19:31 -0800 (PST) In-Reply-To: References: <26501197.ioODuGg76y@thetick> From: R0b0t1 Date: Fri, 10 Nov 2017 17:19:31 -0600 Message-ID: Subject: Re: [gentoo-user] memset_s To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: ab14181a-3849-41d2-9215-1eeb4ee5cd5e X-Archives-Hash: e352cff6735bdaffc63f4a9670e7a143 On Fri, Nov 10, 2017 at 2:09 PM, Jorge Almeida wrote: > On Fri, Nov 10, 2017 at 4:25 PM, R0b0t1 wrote: >> Hello, >> > >> >> I'm having trouble finding the article again, but these functions look >> very similar to Microsoft's extensions to the C standard. There is a >> good case to be made that they are counterproductive. > > Yes, it looks like it. No wonder, if it's MS inspired. But what I care > about is the fact that it's not optimized away, not the boundaries > checking stuff. It's hard to believe that it is practically impossible > to clean up a buffer, unless one is willing to forego all > optimizations: > > http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html > I really think there is a deeper issue here then, which is that the compiler takes a lot of liberties when translating a program description into machine code. There have been suggestions made that this makes very nearly all compilers unsuitable for high reliability purposes. Cryptographic or user security code is likely a candidate for the label "high reliability." To further explain why the additions are counterproductive: the programmer still has to remember to use them. It is just as likely that the programmer will forget to use memset_s properly as any of the other functions in string.h (possibly by forgetting to sanitize input i.e. the memory segment boundaries). > >>> Of course, what would really solve the optimize-into-oblivion problem >>> is a pragma that when invoked on a particular block of code (maybe >>> only a function definition) would tell the compiler to do what the >>> programmer says rather than viewing a function as a kind of black box. >>> >> >> This would probably be useful. It may be wise to reimplement important >> functionality. >> > No idea how difficult it would be to implement, of course. There might > even exist a C keyword for that. After all, the C standard states the > "as-if" rule, it might as well establish such an exception. > Sorry, I misrepresented what I meant. I meant to suggest reimplementing, apart from a standard library, any critical code. This is generally recommended against but unless there is a hand-tuned version that has been guaranteed to work around quirks in your compiler, you are now the person who has to write and maintain that hand-tuned version. If you don't mind I might post this concern to the GCC mailing list, or you can take it up if you want. Cheers, R0b0t1