[PATCH 2/4] getentropy: Add cpu counter based implementation.

Gedare Bloom gedare at rtems.org
Fri Nov 10 20:33:23 UTC 2017


On Fri, Nov 10, 2017 at 2:34 PM, Christian Mauderer
<christian.mauderer at embedded-brains.de> wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Gedare Bloom" <gedare at rtems.org>
>> An: "Christian Mauderer" <christian.mauderer at embedded-brains.de>
>> CC: devel at 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
>>> + *  <rtems at 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.mauderer at 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.



More information about the devel mailing list