Received: by 10.223.185.116 with SMTP id b49csp4416320wrg; Tue, 6 Mar 2018 15:40:56 -0800 (PST) X-Google-Smtp-Source: AG47ELuDn3/SbmJ3PRb9bch9erVsKNQG0UQc3Av0bNDYf+M10RoOyrBWLyomnJzebwR/D2D7IAwz X-Received: by 2002:a17:902:71c9:: with SMTP id t9-v6mr18206660plm.107.1520379656181; Tue, 06 Mar 2018 15:40:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520379656; cv=none; d=google.com; s=arc-20160816; b=nMVcYoZDQ5hhGOFGR7h5BzRfiSRhNS0TA7L32q+1N+GXnD5SOAjrhlv9b63tj+gFyO xQrWDv/qFVd13dkhahyXw1wXgmINujhqGADrpl4QIdeNURyIdnndlgy8Il3LwNW2x5Wf lNsa91eTTjX/9vxoVZmm2vrS+6dCOeH8roKDqxn/is8x7tBQJkixRTttK1kSC/rIQ8Ug bVJ/dI6/nkeAXk45CsOWSBMza/ExfGKGT4yx2p0kcOw5lp0/mkpRNEUtBjvKmvEMVuzV bxNbXgt2MCoK41KY/W9ZUKiBuoWOgMrQyTNHmppKe4B1sLKZvqhEYkpZzRMxBO3XmIhH oxIA== 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:arc-authentication-results; bh=ZNY442ydEx3Ni9tu8Ug1BUJ19OGAF2pVtpvGAFuceec=; b=f/vb2A9T/65U5GU1pMuRfvP+J7Ul6hpSWDhamRbL3eNIf0Cce0MKXtSuCcnQ/crGZs OejlT2QY3nnsfQyU4tXsr+CSPVOzMnd5skZgr/ddJsVWjxynmeo0P2FNJZE+k8Dy9V5C B7sXtCOaCZVw2A5mhgCRhAGBAp9Y68mfs9XG060FUMVRwgYMg+1Gr0eSi290+a8oTozj PwUcI7SSwYXwvE15AtB9Y2Ee77cVrSgrfIudzU4QfADzXtq7t0dDs9WwcWQR3sBDVCkE tgtfIBivqUN/NW4PmDknbJ88LGI4uOIN9LkO59jBBdhHcRVOwbRdyjB529qSalSZmqzb 1h6g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 144si10463236pgd.520.2018.03.06.15.40.40; Tue, 06 Mar 2018 15:40:56 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754268AbeCFXS6 (ORCPT + 99 others); Tue, 6 Mar 2018 18:18:58 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:53664 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754150AbeCFXS5 (ORCPT ); Tue, 6 Mar 2018 18:18:57 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 7B0BA80266; Wed, 7 Mar 2018 00:18:56 +0100 (CET) Date: Wed, 7 Mar 2018 00:18:56 +0100 From: Pavel Machek To: "Jason A. Donenfeld" Cc: LKML , pageexec@freemail.hu Subject: Re: C tricks for efficient stack zeroing Message-ID: <20180306231856.GA28911@amd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > do_something(u8 *output, const u8 *input) > thing1(...) > thing2(...) > thinga(...) > thingb(...) > thingi(...) > thingc(...) > thing3(...) > thing4(...) > thinga(...) > thingc(...) >=20 > Each one of these functions have a few stack variables. The current > solution is to call memzero_explicit() on each of those stack > variables when each function return. But let's say that thingb uses as > much or more stack as thinga. In this case, I'm wasting cycles (and > gcc optimizations) by clearing the stack in both thinga and thingb, > and I could probably get away with doing this in thingb only. > Probably. But to hand estimate those seems a bit brittle. >=20 > What would be really nice would be to somehow keep track of the > maximum stack depth, and just before the function returns, clear from > the maximum depth to its stack base, all in one single call. This > would not only make the code faster and less brittle, but it would > also clean up some algorithms quite a bit. >=20 > Ideally this would take the form of a gcc attribute on the function, > but I was unable to find anything of that nature. I started looking > for little C tricks for this, and came up dry too. I realize I could I'll probably not help you but... Is it possible that code running _with_ zeroing would be actually faster, performance-wise? You know, after calling the crypto function, CPU has 2K of dirty data in its caches. You really don't need that data to be written back to DRAM, you'd prefer that data to be simply discarded. (And it should be easier to discard zeros than to discard non-zero data). Now, I'm not saying common CPUs could take advantage of this, but I believe at least belt machine did something similar in hw ( https://www.youtube.com/watch?v=3DQGw-cy0ylCc&list=3DPLx54dE17v2I2WG7tMybzh= bJ81rTyJMJdU&index=3D2 ) Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlqfIeAACgkQMOfwapXb+vKzOACcCoxBJmNlXleQsSciL4A63llB 2mkAn1Vg2gYSZoygq10Tjtqd7q+NxJF5 =3ix7 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--