Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1985659pxb; Sat, 28 Aug 2021 00:47:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylBwVv7oBQ4ehE3rSsnpNic9vDpe7FQyaOilvpM8VJ9558gM2FW+3bzazP1ZD+D2Y0v87B X-Received: by 2002:a17:906:169a:: with SMTP id s26mr13313924ejd.190.1630136859852; Sat, 28 Aug 2021 00:47:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630136859; cv=none; d=google.com; s=arc-20160816; b=hwz+bJh7PrsL07Zh7hbcgpYXKpcEFa+PA2RElAwWHR9y9Peu/36WDVdXnLN2pSJLDo 7AjnOhtBmZy4uRMdQo3kTkDnZcD0CcgkMqSwUUOYj0PmYCRxnAn023aGCYk3fpmaKw22 TH7VulZpcm+d6iT1t1BNkOMfw/mrDSM3i+IwOZk41Smgt4G9HMlwD6t9HsGrmYPLebz5 7/EjobQuOjdEOwuPRKnxlDaIoE6MSpt5K8+qA29ytZjk6tU14QdIBqia/4JKfN6njQMX 6mYGrKk9odWYw3HEvaVGlavY+nzltWJJC2/NaHub3LiB3+ZAzhGJ1k0HKudnDkkL0iwS E8/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=AK9mFIjyJpl3hXe9Hogzqd/0krNaNdau3tE1oAPxLAs=; b=0SXjyriqEPURjoPE+oINpvOFuJepruC321sAx0MZFWzNU7t8+wXBUyeTf8F8K8vL2e 8NiowEnHLq06THVGPue3Me9CW3swpFHC2KyWF4l/mvs3f+InaBrQxuSCMI/L+n6rRv/U Pc0rK+wQBFRj+z8uEVecrZvXQC+h/I1yIYeLfDXacDVibz+Fq1mID+uYT0cdSLsCFsXo 01rhGLNd2751Dx3BS8uw95zbJvfiM+rEh9MxhanOSEfm9+zzmmQZxxvGeHt/4pBOFdkl qhJ/rULIpjcJbwvA2t/nFpt4a1rHclYXSbULF5CGNEcoQFB4DmXH5gksGPWWex5v6bXF 4leg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="FmFYVV/l"; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk23si8751230edb.444.2021.08.28.00.47.06; Sat, 28 Aug 2021 00:47:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="FmFYVV/l"; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233335AbhH1Hry (ORCPT + 99 others); Sat, 28 Aug 2021 03:47:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230208AbhH1Hry (ORCPT ); Sat, 28 Aug 2021 03:47:54 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0CF8C0613D9; Sat, 28 Aug 2021 00:47:03 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id q11so13890250wrr.9; Sat, 28 Aug 2021 00:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AK9mFIjyJpl3hXe9Hogzqd/0krNaNdau3tE1oAPxLAs=; b=FmFYVV/lxsJ0deuAFIdO4cUnBFNYVdrTzwVm+GLV/zi+BHTq0/mFHfVLoPMUHT8kpK kN8LSNnqAlWJEijL+CFu61aut4oq8y7/Eurwi2hkW3cNVJi7kfhFJ9366PAIGK3QYTQ3 +m1gwqg2EiGnvj7O5D/6SwASdarXWRf1KtQappCEWwzuD+c+ltRQjiDKVNci28+t4i3a qDK55/E3WzuKL1Xc8DNY+tPZZmQrb9P5f4Tzsyb3uQHCARMmLlWzuoHF5apbNwJ3N5ny 63iwsWjdMxlNjQODdOlouEAAy9X1j6lgR0tXppBJcmlYZTxMB6j209kqaSrejsTUuy7j /q+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AK9mFIjyJpl3hXe9Hogzqd/0krNaNdau3tE1oAPxLAs=; b=btvzdszomV7235bngW1RJmGQvBmqZ77ObR6llAg0r4a5SlcsbcYcf2MheCFAYsmzoU GF+ILVNWUq3s1cv78nNoAm1hoz9AaSE0H99bLjeIuexyF1ceoYAWRdFGcU7Gi2a/ovE9 DUTYZmuob3e5Fk/K1pv0SA23lGhSQmwpnt7Wrn7t0JijtKvQyj6nkJE2HH9HsQAQIx/M PnFcxl20LDsd/rZuZYrdtVLLcXjOXzTm5r6FkTFBbhOXbrih/3nNjJbkZXR873zUji2D Z4g4u8eeh5HaFRHW9E5MLCKGW6ux+sOijGdoCCnsrzzZTTA5xu8e9AYxdsaXMnxEINmy Yt1A== X-Gm-Message-State: AOAM533RmA2iNq79zMCMFkS1aW9lfe1M940JBzELDeNBwZrrhQynwkoW agkyakEYNybE8Fej9Pvc7380COyC/RVEeLnFdps= X-Received: by 2002:adf:b7c2:: with SMTP id t2mr5643419wre.375.1630136822435; Sat, 28 Aug 2021 00:47:02 -0700 (PDT) MIME-Version: 1.0 References: <20210822103107.28974-1-lukas.bulwahn@gmail.com> <20210827083842.GF21571@gondor.apana.org.au> In-Reply-To: <20210827083842.GF21571@gondor.apana.org.au> From: Sandy Harris Date: Sat, 28 Aug 2021 15:46:50 +0800 Message-ID: Subject: Re: [PATCH] crypto: sha512: remove imaginary and mystifying clearing of variables To: Herbert Xu Cc: Lukas Bulwahn , "David S . Miller" , Linux Crypto Mailing List , Nathan Chancellor , Nick Desaulniers , clang-built-linux@googlegroups.com, kernel-janitors@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Aug 27, 2021 at 4:40 PM Herbert Xu wrote: > > On Sun, Aug 22, 2021 at 12:31:07PM +0200, Lukas Bulwahn wrote: > > The function sha512_transform() assigns all local variables to 0 before > > returning to its caller with the intent to erase sensitive data. > > .... > > > > The assignments to clear a through h and t1/t2 are optimized out by the > > compiler because they are unused after the assignments. Just no. You are right, there is a problem here. I thank you for pointing it out & I've already fixed it in some of my own code. However, I think your solution is dead wrong. You are correct that these assignments are useless because the compiler will optimise them out, and that's a problem. However, it is not at all "mistiifying"; they are there for an obvious reason, to avoid leaving state that might be useful to an enemy. That is quite a small risk, but then it is a small mitigation, so worth doing. The correct solution is not to just remove the assignments, but rather to replace them with code that will not be optimised away, force the compiler to do what we need. We already do that for operations that clear various arrays and structures, using memzero_explicit() rather than memset(). Similarly, we should replace the assignments with calls to this macro: /* clear a variable in a way the compiler will not optimise out */ #define clear(x) memzero_explicit( &x, sizeof(x) )