Priyanka Panigrahi via llvm-dev
2019-Dec-21 14:08 UTC
[llvm-dev] accessing stack frame after returning from the function
Hello, I have a few general questions. 1. Whether the memory contents assigned for a function are accessible after we return from that function? If yes, how can we access it? 2. Does llvm delete the stackframe assigned for a specific function, after we return from that function? 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? Any help would be appreciated. Thank you. Regards, Priyanka -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191221/d68718be/attachment.html>
Tim Northover via llvm-dev
2019-Dec-22 09:14 UTC
[llvm-dev] accessing stack frame after returning from the function
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.> 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.> 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. Cheers. Tim.
Priyanka Panigrahi via llvm-dev
2019-Dec-23 09:30 UTC
[llvm-dev] accessing stack frame after returning from the function
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>