[llvm-dev] accessing stack frame after returning from the function

Priyanka Panigrahi via llvm-dev llvm-dev at lists.llvm.org
Mon Dec 23 01:30:41 PST 2019

Hi Tim,

Thanks for your fast response.

On Sun, Dec 22, 2019 at 2:44 PM Tim Northover <t.p.northover at gmail.com>

> Hi Priyanka,
> On Sat, 21 Dec 2019 at 14:09, Priyanka Panigrahi via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 1. Whether the memory contents assigned for a function are accessible
> after we return from that function? If yes, how can we access it?
> There's no well defined way to access that memory, but whatever was
> stored there before doesn't get actively cleared to 0 by LLVM so some
> kinds of buffer overrun can see what's there, as can future function
> calls that reuse the space. Both would be undefined behaviour though.

You mean still one can access that memory.

> > 2. Does llvm delete the stackframe assigned for a specific function,
> after we return from that function?
> I'd say yes, but it kind of depends on what you mean by "delete". It
> certainly deallocates the frame.

I mean clearing the original content of the memory by assigning 0 or some
random values. Although it deallocates, the original content is still
there. Right?

> > 3. If not, how can we delete the stackframe or clear the memory content
> after we return from the function? Where do we need to change, in the
> assembly or llvm source?
> If you want to prevent all access for security reasons, you'd probably
> have to modify lib/Target/XYZ/XYZFrameLowering.cpp for each target to
> insert some equivalent of memset(sp, 0, frame_size) at every function
> return. I don't think there's a robust way to achieve it in IR alone.

Thank you for this pointer. I will check it out.

> Cheers.
> Tim.

If you could share with me some publications which work on similar stuff,
it would be great.

Thank you for your time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191223/cfd0c8dc/attachment.html>

More information about the llvm-dev mailing list