[PATCH 02/12] random: Implement read_random via getentropy.

[Gedare Bloom]

On Thu, Aug 2, 2018 at 9:20 AM, Christian Mauderer
<christian.mauderer at embedded-brains.de> wrote:
> Am 02.08.2018 um 15:16 schrieb Gedare Bloom:
>> On Thu, Aug 2, 2018 at 1:28 AM, Christian Mauderer
>> <christian.mauderer at embedded-brains.de> wrote:
>>> Am 01.08.2018 um 16:28 schrieb Gedare Bloom:
>>>> Is this relied on for IPSec? How secure is it?
>>>
>>> Hello Gedare,
>>>
>>> the IPSec implementation in FreeBSD and therefore in RTEMS too uses that
>>> function. So you are right that it is a critical one for security.
>>>
>>> `read_random` is a low-level FreeBSD random number function. From the
>>> man page (see
>>> https://www.freebsd.org/cgi/man.cgi?query=read_random&manpath=FreeBSD+11.2-RELEASE+and+Ports):
>>>
>>>     The read_random() function is used to return entropy directly from
>>>     the entropy device if it has been loaded. If the entropy device is
>>>     not loaded, then the buffer is ignored and zero is returned. The
>>>     buffer is filled with no more than count bytes. It is strongly
>>>     advised that read_random() is not used; instead use arc4rand()
>>>     unless it is necessary to know that no entropy has been returned.
>>>
>>> That's basically the same what our `getentropy` does. Returning entropy
>>> directly from the entropy device if it is available. So it is as close
>>> to the original behavior as we can get.
>>>
>>> Of course `getentropy` only returns a good entropy if there is a real
>>> entropy source in the BSP. Currently that is only true for the atsam
>>> BSP. I think there should be a patch for BBB somewhere on the mailing list.
>>>
>>> We have a chapter in the BSP guide regarding that:
>>>
>>>     https://docs.rtems.org/branches/master/bsp-howto/getentropy.html
>>>
>>> There is also a hint that a good entropy source is necessary for
>>> cryptographic applications. It would be great if you have a good idea
>>> how to make a user aware of the security problem if he doesn't use a
>>> good crypto source.
>>>
>>
>> Thank, this makes sense. It is in my long-range plan to sort out
>> security concerns. I'm not certain the best way to approach it, maybe
>> I will start with a wiki page first.
>
> I agree that addressing security is a good idea. Maybe a checklist in
> the manual with relevant points (like "If you do something with
> encryption: Does your BSP has a good entropy source?")? This page than
> could be referenced throughout the manual or READMEs every time there is
> something security relevant.
>

I'm not opposed to starting/maintaining a security manual, but I'm not
quite organized yet to begin it :)

>>
>>> Best regards
>>>
>>> Christian
>>>
>>>>
>>>> On Wed, Aug 1, 2018 at 4:04 AM, Christian Mauderer
>>>> <christian.mauderer at embedded-brains.de> wrote:
>>>>> ---
>>>>>  freebsd/sys/sys/random.h | 10 ++++++++++
>>>>>  1 file changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/freebsd/sys/sys/random.h b/freebsd/sys/sys/random.h
>>>>> index 396ec2b1..996ca5c1 100644
>>>>> --- a/freebsd/sys/sys/random.h
>>>>> +++ b/freebsd/sys/sys/random.h
>>>>> @@ -50,11 +50,21 @@ read_random_uio(void *a __unused, u_int b __unused)
>>>>>  {
>>>>>         return (0);
>>>>>  }
>>>>> +#ifndef __rtems__
>>>>>  static __inline u_int
>>>>>  read_random(void *a __unused, u_int b __unused)
>>>>>  {
>>>>>         return (0);
>>>>>  }
>>>>> +#else /* __rtems__ */
>>>>> +#include <unistd.h>
>>>>> +static __inline u_int
>>>>> +read_random(void *ptr, u_int n)
>>>>> +{
>>>>> +       getentropy(ptr, n);
>>>>> +       return (n);
>>>>> +}
>>>>> +#endif /* __rtems__ */
>>>>>  #endif
>>>>>
>>>>>  /*
>>>>> --
>>>>> 2.13.7
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> --
>>> --------------------------------------------
>>> embedded brains GmbH
>>> Herr 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.
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr 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.