From patchwork Wed Mar 18 17:14:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: mancha X-Patchwork-Id: 6042181 Return-Path: X-Original-To: patchwork-linux-crypto@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 4F45A9F318 for ; Wed, 18 Mar 2015 17:18:22 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4555F20429 for ; Wed, 18 Mar 2015 17:18:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE90C20414 for ; Wed, 18 Mar 2015 17:18:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932844AbbCRRSS (ORCPT ); Wed, 18 Mar 2015 13:18:18 -0400 Received: from sender1.zohomail.com ([74.201.84.156]:37631 "EHLO sender1.zohomail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933160AbbCRRSR (ORCPT ); Wed, 18 Mar 2015 13:18:17 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to; b=CTO7a+1Ini/60Zvt0RhKvU/LdhPv+P81HNdnKv2ZAWDz68NEK8WtBeHaESIMggEfQwGzn1OmkyYM /nOCpMIZB76ruWS7U/fCxKAjA4EhYF+QMrZFjcfMjXITX4XwCSF6 Received: from zoho.com (dreamatorium.badexample.net [89.31.57.5]) by mx.zohomail.com with SMTPS id 1426699084374912.4041630686523; Wed, 18 Mar 2015 10:18:04 -0700 (PDT) Date: Wed, 18 Mar 2015 17:14:02 +0000 From: mancha To: Stephan Mueller Cc: Hannes Frederic Sowa , Daniel Borkmann , tytso@mit.edu, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au, dborkman@redhat.com, cesarb@cesarb.eti.br Subject: Re: [BUG/PATCH] kernel RNG and its secrets Message-ID: <20150318171402.GB24195@zoho.com> References: <20150318095345.GA12923@zoho.com> <550972A7.9030100@iogearbox.net> <1426691374.2212055.242060697.4DDF89CA@webmail.messagingengine.com> <4937031.1sk5yglzr8@tauon> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4937031.1sk5yglzr8@tauon> X-PGP-Key: http://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x25168eb24f0b22ac X-PGP-FP: 56B7 100E F4D5 811C 8FEF ADD1 2516 8EB2 4F0B 22AC X-Zoho-Virus-Status: 1 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD,T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Mar 18, 2015 at 05:02:01PM +0100, Stephan Mueller wrote: > Am Mittwoch, 18. März 2015, 16:09:34 schrieb Hannes Frederic Sowa: > > Hi Hannes, > > >On Wed, Mar 18, 2015, at 13:42, Daniel Borkmann wrote: > >> On 03/18/2015 01:20 PM, Stephan Mueller wrote: > >> > Am Mittwoch, 18. März 2015, 13:19:07 schrieb Hannes Frederic Sowa: > >> >>>> My proposal would be to add a > >> >>>> > >> >>>> #define OPTIMIZER_HIDE_MEM(ptr, len) __asm__ __volatile__ ("" : > >> >>>> : > >> >>>> "m"( > >> >>>> ({ struct { u8 b[len]; } *p = (void *)ptr ; *p; }) ) > >> >>>> > >> >>>> and use this in the code function. > >> >>>> > >> >>>> This is documented in gcc manual 6.43.2.5. > >> >>> > >> >>> That one adds the zeroization instructuctions. But now there are > >> >>> much > >> >>> more than with the barrier. > >> >>> > >> >>> 400469: 48 c7 04 24 00 00 00 movq $0x0,(%rsp) > >> >>> 400470: 00 > >> >>> 400471: 48 c7 44 24 08 00 00 movq $0x0,0x8(%rsp) > >> >>> 400478: 00 00 > >> >>> 40047a: c7 44 24 10 00 00 00 movl $0x0,0x10(%rsp) > >> >>> 400481: 00 > >> >>> 400482: 48 c7 44 24 20 00 00 movq $0x0,0x20(%rsp) > >> >>> 400489: 00 00 > >> >>> 40048b: 48 c7 44 24 28 00 00 movq $0x0,0x28(%rsp) > >> >>> 400492: 00 00 > >> >>> 400494: c7 44 24 30 00 00 00 movl $0x0,0x30(%rsp) > >> >>> 40049b: 00 > >> >>> > >> >>> Any ideas? > >> >> > >> >> Hmm, correct definition of u8? > >> > > >> > I use unsigned char > >> > > >> >> Which version of gcc do you use? I can't see any difference if I > >> >> compile your example at -O2. > >> > > >> > gcc-Version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) > > > >Well, was an error on my side, I see the same behavior. > > > >> I can see the same with the gcc version I previously posted. So > >> it clears the 20 bytes from your example (movq, movq, movl) at > >> two locations, presumably buf[] and b[]. > > > >Yes, it looks like that. The reservation on the stack changes, too. > > > >Seems like just using barrier() is the best and easiest option. > > Would you prepare a patch for that? > > > >Thanks, > >Hannes > > > Ciao > Stephan Hi. Patch 0001 fixes the dead store issue in memzero_explicit(). However, if the idea is to use barrier() instead of OPTIMIZER_HIDE_VAR() in crypto_memneq() as well, then patch 0002 is the one to use. Please review and keep in mind my analysis was limited to memzero_explicit(). Cesar, were there reasons you didn't use the gcc version of barrier() for crypto_memneq()? Please let me know if I can be of any further assistance. --mancha From cd9e882cd1d684f50c52471d83f9ecf55427c360 Mon Sep 17 00:00:00 2001 From: mancha security Date: Wed, 18 Mar 2015 16:14:34 +0000 Subject: [PATCH] lib/string.c: use barrier() to protect memzero_explicit() OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to ensure protection from dead store optimization. --- lib/string.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/string.c b/lib/string.c index ce81aae..a579201 100644 --- a/lib/string.c +++ b/lib/string.c @@ -607,7 +607,7 @@ EXPORT_SYMBOL(memset); void memzero_explicit(void *s, size_t count) { memset(s, 0, count); - OPTIMIZER_HIDE_VAR(s); + barrier(); } EXPORT_SYMBOL(memzero_explicit);