On Fri, Nov 10, 2017 at 2:34 PM, Christian Mauderer <christian.maude...@embedded-brains.de> wrote: > ----- Ursprüngliche Mail ----- >> Von: "Gedare Bloom" <ged...@rtems.org> >> An: "Christian Mauderer" <christian.maude...@embedded-brains.de> >> CC: devel@rtems.org >> Gesendet: Freitag, 10. November 2017 16:55:33 >> Betreff: Re: [PATCH 2/4] getentropy: Add cpu counter based implementation. > >>> diff --git a/c/src/lib/libbsp/shared/getentropy-cpucounter-based.c >>> b/c/src/lib/libbsp/shared/getentropy-cpucounter-based.c >>> new file mode 100644 >>> index 0000000000..137fdfbb6c >>> --- /dev/null >>> +++ b/c/src/lib/libbsp/shared/getentropy-cpucounter-based.c >>> @@ -0,0 +1,46 @@ >>> +/* >>> + * Copyright (c) 2017 embedded brains GmbH. All rights reserved. >>> + * >>> + * embedded brains GmbH >>> + * Dornierstr. 4 >>> + * 82178 Puchheim >>> + * Germany >>> + * <rt...@embedded-brains.de> >>> + * >>> + * The license and distribution terms for this file may be >>> + * found in the file LICENSE in this distribution or at >>> + * http://www.rtems.org/license/LICENSE. >>> + */ >>> + >>> +#include <unistd.h> >>> +#include <string.h> >>> +#include <rtems/sysinit.h> >>> +#include <rtems/counter.h> >>> + >>> +int getentropy(void *ptr, size_t n) >>> +{ >>> + uint8_t *dest = ptr; >>> + >>> + while (n > 0) { >>> + rtems_counter_ticks ticks; >>> + >>> + ticks = rtems_counter_read(); >>> + >>> + if (n >= sizeof(ticks)) { >>> + memcpy(dest, &ticks, sizeof(ticks)); >>> + n -= sizeof(ticks); >>> + dest += sizeof(ticks); >>> + } else { >>> + /* >>> + * Fill the remaining bytes with only the least >>> + * significant byte of the time. That is the byte >>> with >>> + * the most changes. >>> + */ >>> + *dest = ticks & 0xFF; >>> + --n; >>> + ++dest; >>> + } >>> + } >>> + >>> + return 0; >>> +} >> >> I don't believe this is a good source of entropy--the passage of time >> is not random. Should this be documented as such? > > Hello Gedare, > > I agree that the uptime (or similar things like the CPU counter) isn't a good > entropy source. The only thing that makes it random are interrupts from > external sources. But that is a general problem for embedded systems: There > is no universal entropy source. On desktops a user input is a quite good > source but we don't have anything like that. > > The implementation is intended to be some kind of fallback replacement for > the the even worse one in libbsd: There the source has just filled everything > with zero values. My intention was to make it simpler to integrate true > entropy sources like the atsam TRNG (see patch 4). > Understood.
> Documenting that would be a good idea. Any suggestion where? > A comment in this file, and a note in the BSP Development section of the RTEMS Developer's Manual or whatever document we end up with. > The simplest solution might could be to rename the file to something like > getentropy-pseudo-uptime-based.c. But that would mean that it would still be > only visible to BSP developers. Another possibility would be to print a > message the first time this function is called that warns the user that only > a bad random source is available. But that would clutter the output of > currently any BSP but the atsam when someone uses arc4random (for example > libbsd). > I wouldn't print anything, but just be sure we have a good understanding of the limits of entropy we are using. If it needs to be exposed to user-level, then we should have a section of the User Manual that discusses the issue, or should address it in the API documentation of whatever ends up using it. If it currently only is used through libbsd, then it just needs to be documented from there I suppose. -Gedare > Regards > > Christian > -- > -------------------------------------------- > embedded brains GmbH > Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > Phone: +49-89-18 94 741 - 18 > Fax: +49-89-18 94 741 - 08 > PGP: Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
