This is the mail archive of the
mailing list for the GCC project.
Re: Compiler support for erasure of sensitive data
- From: Andres Tiraboschi <andres dot tiraboschi at tallertechnologies dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Marcos Diaz <marcos dot diaz at tallertechnologies dot com>, zackw at panix dot com, GCC Development <gcc at gcc dot gnu dot org>, Daniel Gutson <daniel dot gutson at tallertechnologies dot com>
- Date: Wed, 9 Mar 2016 11:23:22 -0300
- Subject: Re: Compiler support for erasure of sensitive data
- Authentication-results: sourceware.org; auth=none
- References: <55F0653C dot 9010903 at panix dot com> <1456780462-7500-1-git-send-email-marcos dot diaz at tallertechnologies dot com> <CAFiYyc3OTei5Hxt5kL85CsmZ8iVZDcXK1_+KE2LwMDWxg=_bdQ at mail dot gmail dot com> <20160304122341 dot GB20650 at gate dot crashing dot org>
We are developing this feature for x86_64
I want to see which registers are being used by the current function
for returning a value or as arguments.
I traverse the rtl looking for clobbered registers, but I don't know
how to find which registers are arguments from the current function
and which are used for storing the return value. How do you suggest to
2016-03-04 9:23 GMT-03:00 Segher Boessenkool <email@example.com>:
> On Tue, Mar 01, 2016 at 10:27:00AM +0100, Richard Biener wrote:
>> > We were thinking on making a function attribute that ensures that non necessary registers, or stack frames used by the function will be correctly cleared before returning.
>> > We think in implementing for x86_64 as a first work.
>> > For this we are trying to modify the epilogue generation. Here we should have the information of which registers this function used, and the size of the stack frame to clean. The downside of this is that will be architecture dependent.
>> > Do you think this is a good idea? Do you suggest something else?
>> I think you can't avoid doing architecture specific changes here.
>> Note that on x86_64 you probably want to force
>> to avoid the use of push/pop and have the stack frame freeing fully in
>> the epilogue.
> You'll also need to disable shrink-wrapping for that function.