RTEMS | cpukit/libcrypt: Add SHA3-512 Keccak Implementation (!687)

[Joel Sherrill (@joel)]

Joel Sherrill commented on a discussion on cpukit/include/crypt.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/687#note_130024

 > +/* Code to re-introduce the C11 memset_s function
 > +*  which is missing from the RTEMS C11 compiler but which
 > +*  is used in the libcrypt functions to securely erase
 > +*  sensitive data after use. Since the C11 memset_s
 > +*  function is not available we provide our own implementation
 > +*  here. Should the RTEMS C library ever provide
 > +*  a conforming memset_s function this code can be removed.
 > +*/
 > +static inline void memset_s_rtems(void *s, size_t n) {
 > +	volatile unsigned char *p = (volatile unsigned char *)s;
 > +	while (n--) {
 > +		*p++ = 0;
 > +	}
 > +}
 > +
 > +static inline void explicit_bzero_rtems (void *s, size_t len)

Newlib does not have memset_s(). But this implementation is inefficient. Couldn't it just call memset() which is often optimized for the architecture?

FWIW there is an implementation of the Annex K safe functions on github that I asked them to relicense to permissive and they did for what they could. From an RTEMS perspective, we just haven't done anything since then. Long term, it may make sense to talk to the newlib folks and see if building up the set in newlib makes sense. Not this week and not a rejection of a helper here.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/687#note_130024
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250904/74eaa2bf/attachment-0001.htm>