From: Pavel Machek <pavel@ucw.cz>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: LKML <linux-kernel@vger.kernel.org>, pageexec@freemail.hu
Subject: Re: C tricks for efficient stack zeroing
Date: Wed, 7 Mar 2018 00:18:56 +0100 [thread overview]
Message-ID: <20180306231856.GA28911@amd> (raw)
In-Reply-To: <CAHmME9phM2+ZrdA8jGxOAVnQSvrcO94ekvcgCH4X1xD8Dndiuw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
Hi!
> do_something(u8 *output, const u8 *input)
> thing1(...)
> thing2(...)
> thinga(...)
> thingb(...)
> thingi(...)
> thingc(...)
> thing3(...)
> thing4(...)
> thinga(...)
> thingc(...)
>
> 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.
>
> 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.
>
> 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=QGw-cy0ylCc&list=PLx54dE17v2I2WG7tMybzhbJ81rTyJMJdU&index=2
)
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-03-06 23:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 19:50 C tricks for efficient stack zeroing Jason A. Donenfeld
2018-03-02 21:15 ` Willy Tarreau
2018-03-05 17:06 ` Laura Abbott
2018-03-06 23:18 ` Pavel Machek [this message]
2018-03-07 2:17 ` Julia Cartwright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180306231856.GA28911@amd \
--to=pavel@ucw.cz \
--cc=Jason@zx2c4.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pageexec@freemail.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox