Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp4333481ybp; Mon, 7 Oct 2019 07:01:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqymxgffrblkGNWXxsqWwxQpS22zIkvKSOyo0OwBpzRElp5iKaqBAt0jsYI1h8gvdl71T0OB X-Received: by 2002:a50:934c:: with SMTP id n12mr29521122eda.12.1570456870691; Mon, 07 Oct 2019 07:01:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570456870; cv=none; d=google.com; s=arc-20160816; b=qojVp62sQJsH+g9o4NoUOzEsB0r8dXccDB+Ku3kys4fkiVpvqVWya+mTnT4iqeKVeZ ubeaWNyxcymO+J+ismp+L3KJO0nEIXwLo+4dFSEORm7rCPgIekpRLr6J+zxpXMazDTlE +cw10tun46FLdeuBj4e3+GHSBoHqh0q9khzsTyIlLDJOnahBs+crAPVZYPkOLr7/K9vZ dm3pcGJK/LYPVrVdqyucB6oZ/THsbkSzXPVv5ey9iRT9G7sYQzP100lL0O+FGVAVrCTr KEw/g5/Gc1k2S20knKdF97KYz+VYmbDzwmiCjRdEQ+vjiUqhqIFF+RtNCM8rZnV9fiDr ssfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=LTQi6AkTTCXGOyTWZNioMhV3bvTHe5T1ruIzA19ASxM=; b=gh5iLP5o1z7uFOpAX9pjpqtWbT+VRwWIrRGUtlOXoWO4omi7A4PIxrYdbZfaTGzNe+ OtDWF+bFmwRVPQulu94+wVZfrEi9t4J3C7mXXjeY77VulW0BipUDr4/HmfQg0ULNGVe7 Tl3FhNZ4IZrba5WaBKs/aIR26PrI02kucw2soqj3xPADxLaUvSOlzn5PpGf3iaqWPGED zFbj40OpYUSHC3zKhyAFGiaSLrifiS5PhstplUtOTmb5tfTcyrtROnqMlDBAjy6iAu4Z U7Qm2MAEaOmHAXjwA2J0z0ottdLIp7OHnZEkWi2McPUj3ub7zm6kKxWQ4q/NPCxUCOue fHoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Ec5eQrQE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z7si9715764edi.318.2019.10.07.07.00.44; Mon, 07 Oct 2019 07:01:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Ec5eQrQE; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728017AbfJGOA2 (ORCPT + 99 others); Mon, 7 Oct 2019 10:00:28 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:33441 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727324AbfJGOA1 (ORCPT ); Mon, 7 Oct 2019 10:00:27 -0400 Received: by mail-wm1-f65.google.com with SMTP id r17so106161wme.0; Mon, 07 Oct 2019 07:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=LTQi6AkTTCXGOyTWZNioMhV3bvTHe5T1ruIzA19ASxM=; b=Ec5eQrQETPS4fmIBKOLkJ++AcnN6gM5l5/ss/GzPFzM4k/tPOxRjtlxVfT1sTjhyY/ GnyJUpjY7ekRLAKB+uyJaFgwUReOVX9x55IXQlzzBEDiGnfgwydrBbEblPgFKWHHxJFW N4ZDVDehirClb2LDqMjWWrQZkfcn+gqMPw5R1BZ4NpHeaBuGSGSkUUnFK2wbY1K4hMIq ttRFGExAhQuGdpYLmX0ZlxozPCZBrd/R6uKEqRDmr+J3Ty3xlX5Mkj1it3sgn5WtxDbw BBuPVcS8Uvp+AZhEMwsBPU5cl0wPi6iBMoqgF2MRWjzVmPZRPYsrSZ8QLkvR5qvyQ6QX rocQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=LTQi6AkTTCXGOyTWZNioMhV3bvTHe5T1ruIzA19ASxM=; b=bDSYxmXsBY01hm5YHYs1vJ2glVnK8LkXf0RKo+D43nEcOr+5J87259VYRvXgu954mX dyHvA9kP7wxuGUTAhAq29K09BheFUHlINZwsDcvP8T+otSTgddsCop6bACZ70YO1iFzv R3wCAhwmoljqrujRaEmPNzHq5BYOO77puG9XzY5Z6c+/tnICzmfjCDzscBCRnDu1vPxq bEhT2tXsrGnAQ5Co44boDJK1TfmladM/cJ/D5f9RtokxkM/MLSu/HEM9in8ksyZMD1vB lZxN7fU7pf0Y2OYvI6ZEdrjlwHEYlvilMno4hRLLVJcIUmVdmenZf7GkTvcl8fEoOWEF gCrw== X-Gm-Message-State: APjAAAXNZlPo372ejbqSuMk1EuTzkNnz82xDHHNKrNihGkwFVP+ZjLBP YrGbW2bxXHjNojTDwdStWsk= X-Received: by 2002:a05:600c:118a:: with SMTP id i10mr20538894wmf.80.1570456825315; Mon, 07 Oct 2019 07:00:25 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id y19sm34357804wmi.13.2019.10.07.07.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Oct 2019 07:00:24 -0700 (PDT) Date: Mon, 7 Oct 2019 16:00:22 +0200 From: Ingo Molnar To: Hans de Goede Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Herbert Xu , Ard Biesheuvel , linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Arvind Sankar Subject: Re: [PATCH v2 5.4 regression fix] x86/boot: Provide memzero_explicit Message-ID: <20191007140022.GA29008@gmail.com> References: <20191007134724.4019-1-hdegoede@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191007134724.4019-1-hdegoede@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Hans de Goede wrote: > The purgatory code now uses the shared lib/crypto/sha256.c sha256 > implementation. This needs memzero_explicit, implement this. > > Reported-by: Arvind Sankar > Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit") > Signed-off-by: Hans de Goede > --- > Changes in v2: > - Add barrier_data() call after the memset, making the function really > explicit. Using barrier_data() works fine in the purgatory (build) > environment. > --- > arch/x86/boot/compressed/string.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/boot/compressed/string.c b/arch/x86/boot/compressed/string.c > index 81fc1eaa3229..654a7164a702 100644 > --- a/arch/x86/boot/compressed/string.c > +++ b/arch/x86/boot/compressed/string.c > @@ -50,6 +50,12 @@ void *memset(void *s, int c, size_t n) > return s; > } > > +void memzero_explicit(void *s, size_t count) > +{ > + memset(s, 0, count); > + barrier_data(s); > +} So the barrier_data() is only there to keep LTO from optimizing out the seemingly unused function? Is there no canonical way to do that, instead of a seemingly obscure barrier_data() call - which would require a comment at minimum. We do have $(DISABLE_LTO), not sure whether it's applicable here though. Thanks, Ingo