From patchwork Wed Mar 18 09:53:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: mancha X-Patchwork-Id: 6037791 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 2F7039F39E for ; Wed, 18 Mar 2015 10:12:45 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8651F204EC for ; Wed, 18 Mar 2015 10:12:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9CCCE203F1 for ; Wed, 18 Mar 2015 10:12:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755485AbbCRKMm (ORCPT ); Wed, 18 Mar 2015 06:12:42 -0400 Received: from sender1.zohomail.com ([74.201.84.157]:38693 "EHLO sender1.zohomail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754850AbbCRKMl (ORCPT ); Wed, 18 Mar 2015 06:12:41 -0400 X-Greylist: delayed 915 seconds by postgrey-1.27 at vger.kernel.org; Wed, 18 Mar 2015 06:12:41 EDT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:cc:subject:message-id:mime-version:content-type; b=EG+n2DBo4t9qQArJwSylJtO7jNMNFKmZJQGdWODpkAW4WGmZfiNOrq1xcchmmQUNIVV7jSymc10I WFNrfhhMYRqa9BB+4UP1rj7HOoL84l4PAWpNIpHRvfAf2WcGqHsb Received: from zoho.com (tor-exit0-readme.dfri.se [171.25.193.20]) by mx.zohomail.com with SMTPS id 1426672637050134.8205404976169; Wed, 18 Mar 2015 02:57:17 -0700 (PDT) Date: Wed, 18 Mar 2015 09:53:45 +0000 From: mancha To: tytso@mit.edu, linux-kernel@vger.kernel.org Cc: linux-crypto@vger.kernel.org, herbert@gondor.apana.org.au, dborkman@redhat.com Subject: [BUG/PATCH] kernel RNG and its secrets Message-ID: <20150318095345.GA12923@zoho.com> MIME-Version: 1.0 Content-Disposition: inline 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 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)) and __asm__ __volatile__("": : :"memory") The first is OPTIMIZER_HIDE_VAR plus a volatile qualifier and the second is barrier() [as defined when using gcc]. I propose memzero_explicit use barrier(). For any attribution deemed necessary, please use "mancha security". Please CC me on replies. --mancha PS CC'ing Herbert Xu in case this impacts crypto_memneq. --- a/lib/string.c +++ b/lib/string.c @@ -616,7 +616,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);