https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
--- Comment #8 from Marcos Diaz <marcos.diaz at tallertechnologies dot com> --- Created attachment 37971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37971&action=edit An implementation for x86 security_sensitive function attribute Hi, we made this patch, that adds an attribute 'security_sensitive' only for x86_64 arch. But we wanted your opinion about some decisions we made. When you use a function with this new attribute, it does two things in the function's epilogue: clears all the used stack of the current function. clears all the regs that this function uses and aren't preserved or used to return a value from the function. To clear the stack we use the stack_pointer_offset member of the current frame. I think this isn't handling the case when we use the stack to pass arguments to another function. Is this correct? Should this attribute also clean that part of the stack? Where can we look the stack used for that purpose? Should we force maccumulate-outgoing-args as suggested? We also disabled the using of the red zone for the function with the attribute, but we were thinking that this may not be necessary, since we can also clear that part of the stack. What do you think? We chose to clear the stack in a point of the epilogue where the stack pointer is set in the return address. This way we can clear almost all the stack. But we are clearing parts that aren't 'covered' by the current sp. Is this Ok? or should we clear the stack while the sp is at the bottom of the frame? We decided not to clear the registers when a sibcall is going to be made. Do you think this is correct? We needed to know which registers are used to return something, so we used the ix86_function_value function. Is this approach correct or is this information somewhere else? We aren't handling the case when a function doesn't use its arguments. in those cases we aren't clearing the args registers or stack. Do you think this is correct? We tried to add the noinline attribute when the security_sensitive attribute is set, but it didn't work so we used DECL_UNINLINABLE directly. Is this OK? if not, How do you add another attribute when you 'parse' an attribute? How does shrink-wrapping affect us? Since in the mailing list somebody mentioned we should disable it. Any other question or problem you see please let us know. Thanks, and sorry for the long post.
