Re: Avoiding stack buffer clear being optimised out

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 01/12/2022 11:31, Jonathan Wakely wrote:
> On Thu, 1 Dec 2022 at 10:44, Jonny Grant wrote:
>> Thank you Jonathan and David for your replies.
>>
>> That "noipa" looks to have sorted this issue
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>>
>> That page also suggests "noinline" attribute which seems to suggest I'd need to add asm (""); in each wrapper of memset()
> 
> I already used the noinline attribute in my example above.
> 
>> I'd much rather have memset_s - Jonathan, do you think GCC could add some built-in functions for memset_s ?     __builtin_memset_s() would be great.
> 
> No.
> 
> But C2x adds a memset_explicit function that does what you want, so
> that should arrive in glibc soonish.
> I thought it had been added, but was searching the C2x draft for
> "memset_secure" and other incorrect names.
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2631.htm was the
> proposal adding it.

Well, at least it is in the standard. Although now we have yet another function name doing similar.
Might have been simpler to add explicit_bzero to the standard.

I can see this has been discussed for two decades
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537

So it will be like this:
void *memset_explicit(void *s, int c, size_t n);

I imagine it won't check the pointer is non-NULL. memset_s did do that. Seems pointless to return the pointer.

Hopefully no one will use these other variations people have implemented with different parameter types.
https://github.com/gsbabil/memset_explicit/blob/master/memset_explicit.h

>>
>> There are quite a few similar ones that should be easy to add based on existing
>>  (memcpy_s, memmove_s, strcpy_s, strncpy_s, strcat_s, strncat_s, strtok_s, memset_s, strerror_s, strerrorlen_s, strnlen_s).
> 
> They're not good APIs. See
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm and
> https://sourceware.org/legacy-ml/libc-help/2018-01/msg00007.html

Yes, I know there is a lot of disapproval of Annex K. although I don't feel those trivial memset_s style are. I liked them as they check for non-NULL and return a handy error code.

Regards, Jonny



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux