[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>
wrote:

> 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.

Regards,
Priyanka
-------------- 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