From: Julia Cartwright <juliac@eso.teric.us>
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: Tue, 6 Mar 2018 20:17:08 -0600 [thread overview]
Message-ID: <20180307021708.GC1924@kryptos.localdomain> (raw)
In-Reply-To: <CAHmME9phM2+ZrdA8jGxOAVnQSvrcO94ekvcgCH4X1xD8Dndiuw@mail.gmail.com>
On Fri, Mar 02, 2018 at 08:50:17PM +0100, Jason A. Donenfeld wrote:
[..]
> 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
> probably just take the current stack address and zero out until _the
> very end_ but that seems to overshoot and would probably be bad for
> performance. The best I've been able to do come up with are some
> x86-specific macros, but that approach seems a bit underwhelming.
> Other approaches include adding a new attribute via the gcc plugin
> system, which could make this kind of thing more complete [cc'ing
> pipacs in case he's thought about that before].
Can objtool support a static stack usage analysis?
I'm wondering if it's possible to place these sensitive functions in a
special linker section, like .text.stackzero.<tag>; objtool could
collect static call data (as it already does) and stack usage, spitting
out a symbol definition stackzero_<tag>_max_depth, which you could then
use to bound your zeroing.
Obviously this is a static analysis, with the limitations therein.
Julia
prev parent reply other threads:[~2018-03-07 2:17 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
2018-03-07 2:17 ` Julia Cartwright [this message]
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=20180307021708.GC1924@kryptos.localdomain \
--to=juliac@eso.teric.us \
--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;
as well as URLs for NNTP newsgroup(s).