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 CB8951396D9 for ; Sat, 11 Nov 2017 00:10:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C3CBFE0FDF; Sat, 11 Nov 2017 00:10:41 +0000 (UTC) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 66BECE0FD5 for ; Sat, 11 Nov 2017 00:10:41 +0000 (UTC) Received: by mail-ot0-x241.google.com with SMTP id j29so6107845oth.13 for ; Fri, 10 Nov 2017 16:10:41 -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=BBjbwUOXTH2uKdZPhGuzcViB/L3MaFVsdRZA2jEac0s=; b=T8GRG57hqzkyOen4puNLVUbChKftcqfso4ZiL5pqS8qVLU8O43F09I1RgKz+Y7zbk/ TvZp02yu6koB8Cg7HVfAk3kCaTCjI9OP6NUSEoO9473GRtyYWPLZihf0U5iyxq0xwmH0 qEcQV0dqgYZ8wrvm9RQ0O6NeoZ8F6KDkKA03AHTlfHBDaX0A3I9hupW5ix7WpYyDQjYJ /tINA6tWEOgKsxwd3EX8bqUnRJdSbM4dzRqmXHFs/zYj4AqFYzNj4QaCNqM/9pzzYJPZ TJ3iDpJRrNKR5j9y0Mj2yjSjmQFlnPH6cyRPHJ5IbS6Ar9NdvJh7NZBbapvWcV/gQwsC JlQQ== 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=BBjbwUOXTH2uKdZPhGuzcViB/L3MaFVsdRZA2jEac0s=; b=dOl7s+vvOnUo88u02lrp5ByqNQod2Tz3W8CRcqdLmwpHpu46ISfEMAt4RAS+C68BSW egHIX6jC54TT2Mgq4ElfKZvYp0xT8J/B5KZfuDyBrHiydTIQTY3HzdZZSsAbPH+q2E+d GqCVzCXYn1iZAC0k4JqcNaufS6ec3N87TbW/mAoGJ1hKqSizbXaHnM+82e6wurmpSxU8 cTlaeWFL3/VYm2YJoNMtCO+9KWnyxlN2VWQd5ugbPWG2+A6wB12rbtgsGUHZp4gCEiJN z0Jla0SdtDr8MuidjY8da21n+bzQnaw9RN1IN695/0I5djbkkJCU0OPA+dzmAYx7y5c2 RO7w== X-Gm-Message-State: AJaThX5jWf1XfpxLYrt+C0YfI+zmnrCXmEact8bzn6/e3MFfIvkQmrmM VnBnZ9bIvr/KgSkTqGos28UbQVujrpCsHwhMOaE= X-Google-Smtp-Source: AGs4zMaYkN89zIEEA/rrH/OckgGw3wyCrk8fFzDRsL5TrsIPdNYblwX9v9VNS95zZ52+lI1teUQwCCnQHsu/eAqVI/Q= X-Received: by 10.157.23.15 with SMTP id i15mr1242869ota.424.1510359040229; Fri, 10 Nov 2017 16:10:40 -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.157.83.24 with HTTP; Fri, 10 Nov 2017 16:10:19 -0800 (PST) In-Reply-To: References: <26501197.ioODuGg76y@thetick> From: Jorge Almeida Date: Sat, 11 Nov 2017 00:10:19 +0000 Message-ID: Subject: Re: [gentoo-user] memset_s To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 40e794da-cf30-4af6-8c73-3e9702728b02 X-Archives-Hash: a318ce594ac825403d726fbb5ebe0d2d On Fri, Nov 10, 2017 at 11:19 PM, R0b0t1 wrote: > On Fri, Nov 10, 2017 at 2:09 PM, Jorge Almeida wrote: >> On Fri, Nov 10, 2017 at 4:25 PM, R0b0t1 wrote: > >> >> 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." Yes, the html page above has a link to a 2nd part, where (if I understood correctly) it is concluded that currently there is no real solution: even if the compiler does what it is told to, it may copy data around, and the programmer has no control whatsoever over the fate of such data. > > 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). > 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. > > > If you don't mind I might post this concern to the GCC mailing list, > or you can take it up if you want. Please do. I'm strictly amateur league, and you'll do a better job. > Cheers Jorge