From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755964AbbCRKuR (ORCPT ); Wed, 18 Mar 2015 06:50:17 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:50513 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755925AbbCRKuM (ORCPT ); Wed, 18 Mar 2015 06:50:12 -0400 Message-Id: <1426675809.2143223.241946097.20888470@webmail.messagingengine.com> X-Sasl-Enc: MAR2d6ztW18DVv1EU3RjGq6rNDI9RsavzmqAhs6GYGbf 1426675809 From: Hannes Frederic Sowa To: mancha , tytso@mit.edu, linux-kernel@vger.kernel.org Cc: linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au, dborkman@redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15db86eb In-Reply-To: <20150318095345.GA12923@zoho.com> References: <20150318095345.GA12923@zoho.com> Subject: Re: [BUG/PATCH] kernel RNG and its secrets Date: Wed, 18 Mar 2015 11:50:09 +0100 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 18, 2015, at 10:53, mancha wrote: > Hi. > > The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect > memory cleansing against things like dead store optimization: > > void memzero_explicit(void *s, size_t count) > { > memset(s, 0, count); > OPTIMIZER_HIDE_VAR(s); > } > > OPTIMIZER_HIDE_VAR, introduced in fe8c8a126806 to protect crypto_memneq > against timing analysis, is defined when using gcc as: > > #define OPTIMIZER_HIDE_VAR(var) __asm__ ("" : "=r" (var) : "0" (var)) > > My tests with gcc 4.8.2 on x86 find it insufficient to prevent gcc from > optimizing out memset (i.e. secrets remain in memory). > > Two things that do work: > > __asm__ __volatile__ ("" : "=r" (var) : "0" (var)) You are correct, volatile signature should be added to OPTIMIZER_HIDE_VAR. Because we use an output variable "=r", gcc is allowed to check if it is needed and may remove the asm statement. Another option would be to just use var as an input variable - asm blocks without output variables are always considered being volatile by gcc. Can you send a patch? I don't think it is security critical, as Daniel pointed out, the call will happen because the function is an external call to the crypto functions, thus the compiler has to flush memory on return. Bye, Hannes