RNG HAL addition #2765

0xc0170 · 2016-09-21T08:45:32Z

Description

Add RNG HAL API + mbedtls wrapper to use it. There are 4 functions, 3 are implemented for all targets (port from the old implementation to the new one):

init
free
get random numbers
set seed (this one is just a proposal, would like to get your feedback, and I'll port it for all targets)

Status

IN DEVELOPMENT

Todos

Tests
Review by mbedtls team

@sg- @sbutcher-arm @andresag01 @yanesca @pjbakker - please review

simonbutcher · 2016-09-21T09:00:33Z

features/mbedtls/mbed/wrapper.c

@@ -0,0 +1,29 @@
+/* mbed Microcontroller Library


I think we need a more descriptive filename such as mbed_rng.c. wrapper.c isn't very descriptive.

I'm also not sure this is the best place to put the file (although I have no better suggestions yet).

mbed_rng.c +1 , will rebase

Note: I'll rebase (correct this name) once the review is done .

simonbutcher · 2016-09-21T09:11:00Z

features/mbedtls/mbed/wrapper.c

+
+int mbedtls_hardware_poll( void *data, unsigned char *output, size_t len, size_t *olen ) {
+    rng_t rng_obj;
+    rng_init(&rng_obj);


I'm not sure it's a good idea to bring up and teardown the RNG per poll, dependent on hardware.

A lousy RNG might start giving us the same sequence of values after each initialisation. Better for an initialisation function called earlier by mbed TLS, and maybe a suspend/awake pair of functions for power management.

This was taken from mbedtls_hardware_poll implementation within mbed. Most of the functions in HAL did it - init, get numbers, deinit. I havent seen any other function that we could connect init/free into. I assume this would be a new addition?

simonbutcher · 2016-09-21T09:14:47Z

features/mbedtls/mbed/wrapper.c

+
+#if defined(MBEDTLS_ENTROPY_HARDWARE_ALT) && defined(DEVICE_RNG)
+
+int mbedtls_hardware_poll( void *data, unsigned char *output, size_t len, size_t *olen ) {


If we tie the RNG into the entropy source API, it becomes our only possible entropy source. Is that what we want to do?

I think the RNG driver should be the default entropy source, but do we want it to be the only one?

How can we make it not the only choice? How is this configurable with mbedtls?

simonbutcher · 2016-09-21T09:17:19Z

hal/hal/rng_api.h

+
+#if DEVICE_RNG
+
+/** RNG HAL structure. rng_s is declared in the target's HAL


Throughout, we call this the mbed RNG HAL API. Can we make it clear this needs to be for a TRNG?

I followed the API and vendors naming, most of peripherals I have seen are called RNG.

Can we make it clear this needs to be for a TRNG

Proposing to add a comment or to rename the prefix to trng_?

simonbutcher · 2016-09-21T09:18:27Z

features/mbedtls/mbed/wrapper.c

+
+#include "hal/rng_api.h"
+
+#if defined(MBEDTLS_ENTROPY_HARDWARE_ALT) && defined(DEVICE_RNG)


Can we change DEVICE_RNG to DEVICE_HW_RNG? I'd like to be clearer that it's got to be a TRNG.

This comes from mbed, where we use DEVICE_ for instance DEVICE_SPI. Anything starting with that prefix, is HAL related

DEVICE_TRNG then?

Can we please change the symbol to DEVICE_TRNG?

simonbutcher · 2016-09-21T09:20:04Z

hal/hal/rng_api.h

+ * @param output_length The length of generated data
+ * @return 0 success, -1 fail
+ */
+int rng_get_numbers(rng_t *obj, uint8_t *output, size_t length, size_t *output_length);


Is this going to be thread safe? (open question and needs to be checked)

mbed TLS, as a library, often leaves concurrency issues to the application software above it, or the hardware drivers underneath it.

The above layer (caller) should implement thread safety. mbed HAL is not thread-safe.

Please don't use numbers! get_random() or get_random_bytes() or get_bytes()... But don't use numbers (anywhere in the code for that matter).

Also although our interface looks the same right now, but we may add a new int* parameter in order to make it possible to indicate the number of bits of entropy in the output buffer, because we will need it in the future.

get_bytes() sounds good, will rename

@yanesca

Also although our interface looks the same right now, but we may add a new int* parameter in order to make it possible to indicate the number of bits of entropy in the output buffer, because we will need it in the future.

What would the new API look like, please paste here a declaration.

Something like:

int rng_get_numbers(rng_t *obj, uint8_t *output, size_t length, size_t *output_length, uint8_t *output_number_bits);

?

simonbutcher · 2016-09-21T09:23:20Z

hal/hal/rng_api.h

+#include "device.h"
+
+#if DEVICE_RNG
+


To avoid user application software taking all the entropy, we should make it clear in some comment that this API is for the exclusive use of mbed TLS when present.

Ideally, we should have some lock to restrict it to mbed TLS only. (Although I'm not sure how we could do that without cost).

If I add a comment there that there should be only one consumer of this API , would that be sufficient?

mbed HAL is not user-facing API (there has been always a warning that this API might change, and should not be used in the user space), there're mbed drivers there .

simonbutcher · 2016-09-21T09:27:05Z

features/mbedtls/mbed/wrapper.c

+
+#include "hal/rng_api.h"
+
+#if defined(MBEDTLS_ENTROPY_HARDWARE_ALT) && defined(DEVICE_RNG)


I'm not sure we should require MBEDTLS_ENTROPY_HARDWARE_ALT if we have DEVICE_RNG. I think mbed TLS should self-configure. That would require a change to mbed TLS.

simonbutcher

Some review feedback needs discussion.

simonbutcher · 2016-09-21T09:29:57Z

hal/hal/rng_api.h

+ * @param obj The RNG object
+ * @param seed_value Entropy value to be set
+ */
+void rng_set_seed(rng_t *obj, uint32_t seed_value);


I'm not sure I like this function. mbed TLS doesn't need to seed it, and it's supposed to be a TRNG. If a hardware block needs seeding, maybe better to let the driver handle this itself.

If a hardware block needs seeding, maybe better to let the driver handle this itself.

That's what I was not certain about and added it here with a question mark. get_numbers would implement seeding if required as you stated.

simonbutcher · 2016-09-21T10:11:05Z

hal/targets/hal/TARGET_NUVOTON/TARGET_NUC472/rng_api.c

    PRNG_DISABLE_INT();
    NVIC_DisableIRQ(CRPT_IRQn);
-//    CLK_DisableModuleClock(CRPT_MODULE);
-
+    //CLK_DisableModuleClock(CRPT_MODULE);


Commented out line? This doesn't look good.

yeah, I havent cleaned yet that file, there are lot of commented lines, will do

simonbutcher · 2016-09-21T10:15:30Z

hal/hal/rng_api.h

+ * @param seed_value Entropy value to be set
+ */
+void rng_set_seed(rng_t *obj, uint32_t seed_value);
+


Should we also have a function for a self-test that mbed TLS could run as part of it's own self-verification?

What would be the name and purpose? I don't follow what self-verification means

simonbutcher · 2016-09-21T10:17:58Z

hal/hal/rng_api.h

+#if DEVICE_RNG
+
+/** RNG HAL structure. rng_s is declared in the target's HAL
+ */


mbed TLS has an interface for an entropy source, whilst this is an interface for a driver for a HW RNG. Is that correct, or do we really want an interface for an entropy source?

@pjbakker suggested it makes most sense for this to remain as a TRNG API, which I think is correct, but if so, partners may not want to implement this API and instead stick with the existing API - so we'd still need both means of porting an entropy source.

This should be for HW RNG. Interface for entropy would be built on top of it.

partners may not want to implement this API and instead stick with the existing API

Can you elaborate? Do you mean that they have implemented mbedtls_hardware_poll and want to use that one?

andresag01 · 2016-09-21T10:51:51Z

hal/targets.json

@@ -565,7 +565,7 @@
        "inherits": ["Target"],
        "progen": {"target": "frdm-k64f"},
        "detect_code": ["0240"],
-        "device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "STORAGE"],
+        "device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "STORAGE", "RNG"],


This PR contradicts our own to introduce the self tests #2716. This is because we are introducing a new macro DEVICE_ENTROPY_SOURCE to tell whether the config.h in use should be the default or a trimmed-down one that only enables features that do not require and entropy source to work. If we merge both PR we have two symbols that then would overlap (RNG and DEVICE_ENTROPY_SOURCE). That is, if we remove one of the symbols in both PRs, that would cause some issues because the RNG is not the only entropy source that could be supported in the future.

what are you suggesting?

andresag01 · 2016-09-21T10:54:38Z

hal/targets/hal/TARGET_Freescale/TARGET_KSDK2_MCUS/TARGET_K66F/rng_api.c


    /* Set "Interrupt Mask", "High Assurance" and "Go",
     * unset "Clear interrupt" and "Sleep" */
    RNG->CR = RNG_CR_INTM_MASK | RNG_CR_HA_MASK | RNG_CR_GO_MASK;

-    for( i = 0; i < len; i++ )
-        rng_get_byte( output + i );
+    for (i = 0; i < length; i++) {


If you are going to change the formatting in this function, it would be ideal if you also fix rng_get_byte()

andresag01 · 2016-09-21T10:56:06Z

hal/targets/hal/TARGET_Freescale/TARGET_KSDK2_MCUS/TARGET_K66F/rng_api.c

- */
-int mbedtls_hardware_poll( void *data,
-                    unsigned char *output, size_t len, size_t *olen )
+int rng_get_numbers(rng_t *obj, uint8_t *output, size_t length, size_t *output_length)


I have not compiled this, but I believe this would probably cause an unused parameter obj warning?

andresag01 · 2016-09-21T10:57:11Z

hal/targets/hal/TARGET_Freescale/TARGET_KSDK2_MCUS/TARGET_MCU_K64F/rng_api.c

- */
-int mbedtls_hardware_poll( void *data,
-                    unsigned char *output, size_t len, size_t *olen )
+int rng_get_numbers(rng_t *obj, uint8_t *output, size_t length, size_t *output_length)


Same as before, this would probably cause an unused parameter obj warning.

andresag01 · 2016-09-21T11:03:13Z

hal/targets/hal/TARGET_Freescale/TARGET_KSDK2_MCUS/api/objects.h

@@ -61,6 +61,10 @@ struct dac_s {
    DACName dac;
 };

+struct rng_s {


I understand why mbedtls has a void * as a first parameter. Indeed, the API should even work when the value of the parameter is NULL. However, I am not entirely sure why this API has a first parameter which is a completely empty structure. Perhaps, at least there should be a way to tell whether it has been initialised or something like this?

that's the C HAL convention to avoid having global data in C HAL. Not all HAL implementation require private data, therefore for some platforms it might be empty structure.

andresag01 · 2016-09-21T11:05:16Z

hal/targets/hal/TARGET_NUVOTON/TARGET_NUC472/rng_api.c

-
-int mbedtls_hardware_poll( void *data,
-                    unsigned char *output, size_t len, size_t *olen )
+int rng_get_numbers(rng_t *obj, uint8_t *output, size_t length, size_t *output_length)


Same issue as before with parameter obj.

andresag01 · 2016-09-21T11:07:11Z

hal/targets/hal/TARGET_NUVOTON/TARGET_NUC472/rng_api.c

+    if (length < 32) {
+        unsigned char tmpBuff[32];
+        rng_get(tmpBuff);
+        memcpy( output, &tmpBuff, length );


Please do not use different coding styles.

That file needs a clean up , will do. Did not intend to make more noise changing the style, I did for some lines I touched though :-)

0xc0170 · 2016-09-21T12:09:31Z

Pushed an update (to answer some of the above comments)

0xc0170 · 2016-09-21T16:30:16Z

Removed set seed function and rename RNG to TRNG as requested and rebased to resolve build errors.

sg- · 2016-09-22T04:28:38Z

features/mbedtls/mbed_rng.c

@@ -0,0 +1,29 @@
+/* mbed Microcontroller Library


file name to be mbed_trng.c ?

sg- · 2016-09-22T04:29:04Z

hal/hal/trng_api.h

+
+#if DEVICE_TRNG
+
+/** tRNG HAL structure. trng_s is declared in the target's HAL


sg- · 2016-09-22T04:29:57Z

hal/hal/trng_api.h

+#endif
+
+/**
+ * \defgroup hal_trng tRNG hal functions


sg- · 2016-09-22T04:30:02Z

hal/hal/trng_api.h

+ * @{
+ */
+
+/** Initialize the tRNG peripheral


sg- · 2016-09-22T04:30:06Z

hal/hal/trng_api.h

+
+/** Initialize the tRNG peripheral
+ *
+ * @param obj The tRNG object


sg- · 2016-09-22T04:32:33Z

hal/targets/hal/TARGET_Freescale/TARGET_KSDK2_MCUS/TARGET_K66F/rng_api.c

@@ -26,12 +26,27 @@
 #include "cmsis.h"
 #include "fsl_common.h"
 #include "fsl_clock.h"
+#include "trng_api.h"


file name to be trng_api.c?

sg- · 2016-09-22T04:33:05Z

hal/targets/hal/TARGET_Freescale/TARGET_KSDK2_MCUS/TARGET_MCU_K64F/rng_api.c

@@ -26,58 +26,58 @@
 #include "cmsis.h"
 #include "fsl_common.h"
 #include "fsl_clock.h"
+#include "trng_api.h"


file name to be trng_api.c?

sg- · 2016-09-22T04:33:36Z

hal/targets/hal/TARGET_NUVOTON/TARGET_NUC472/rng_api.c

@@ -0,0 +1,99 @@
+/*


file name to be trng_api.c?

sg- · 2016-09-22T04:34:08Z

hal/targets/hal/TARGET_STM/TARGET_STM32F4/rng_api.c

@@ -25,58 +25,53 @@
    defined(TARGET_STM32F479xx)
 #include <stdlib.h>
 #include "cmsis.h"
+#include "trng_api.h"


file name to be trng_api.c?

sg- · 2016-09-22T04:34:24Z

hal/targets/hal/TARGET_STM/TARGET_STM32F7/rng_api.c

@@ -21,58 +21,52 @@

 #include <stdlib.h>
 #include "cmsis.h"
+#include "trng_api.h"


file name to be trng_api.c?

0xc0170 · 2016-09-22T07:38:29Z

The renames were fixed and rebased on top of master to resolve conflicts.

Fixing all build problems now

andresag01 · 2016-09-22T08:50:53Z

hal/hal/trng_api.h

+#include <stddef.h>
+#include "device.h"
+
+#if DEVICE_TRNG


This might just be a cosmetic change, but perhaps this should be #if defined(DEVICE_TRNG)?

I was about to change it this morning then realized this is how it is within HAL (if we go that path, should be fixed everywhere). lets keep it as it is

yanesca · 2016-09-22T10:56:45Z

hal/hal/trng_api.h

+int trng_get_bytes(trng_t *obj, uint8_t *output, size_t length, size_t *output_length);
+
+/**@}*/
+


We also would need a int trng_get_min_entropy() function that returns an estimate on the min entropy of the TRNG. The amount of entropy returned by each call of trng_get_bytes MUST be at least this much. This is usually a static value, a characteristic of the hardware and the driver. (The amount of entropy in a single returned byte can be anything between 0 and 8)

mbed TLS will call this function automatically and use this value to calculate how many times we have to poll to achieve the configured level of cryptographic strength.

We may want to put a reference in a comment on how to estimate the entropy of a source. Section 6 in the standard: http://csrc.nist.gov/publications/drafts/800-90/sp800-90b_second_draft.pdf describes it in great detail with easy to follow implementation instructions.

You probably discussed this with the others, but just to be sure I write it here too: The trng_get_min_entropy function is not necessary for this release. It is postponed and it will be redesigned before implementation.

0xc0170 · 2016-09-22T13:10:59Z

@yanesca I added int trng_get_minimum_entropy(trng_t *obj). Please review the implementations, I could not find details for nuvoton or STM32F4/F7 for this function though

yanesca · 2016-09-22T13:31:01Z

hal/hal/trng_api.h

+int trng_get_bytes(trng_t *obj, uint8_t *output, size_t length, size_t *output_length);
+
+/** Get minimum entropy bits per byte returned via get_bytes function
+ *


We may want to put a reference in a comment on how to estimate the entropy of a source. Section 6 in the standard: http://csrc.nist.gov/publications/drafts/800-90/sp800-90b_second_draft.pdf describes it in great detail with easy to follow implementation instructions.

What may worth pointing out:

these tests described in the standard shouldn't be performed by this function

they should be performed separately "offline" and the resulting estimate supplied as a constant in the implementation of this function

this value must be a lower estimate

trng_get_bytes must be implemented in a way that it returns at least one bit of entropy (Example: if the entropy estimate for a 4 byte value is 0.35 bit, then trng_get_bytes must load at least 12 bytes in the output buffer)

yanesca · 2016-09-22T13:34:05Z

hal/hal/trng_api.h

+ *
+ * @param obj The TRNG object
+ * @param output The pointer to an output array
+ * @param length The length of output data


We may want to clarify here that this is the size of the output buffer, they don't have to fill this buffer before returning, this value is only there only to help them avoid a buffer overwrite.

yanesca · 2016-09-22T13:38:50Z

hal/hal/trng_api.h

+ */
+int trng_get_bytes(trng_t *obj, uint8_t *output, size_t length, size_t *output_length);
+
+/** Get minimum entropy bits per byte returned via get_bytes function


It should return the number of bits of entropy per call returned via get_bytes function and not per bytes.

0xc0170 · 2016-09-22T14:22:47Z

@yanesca Docs fixed according to your comments above

simonbutcher · 2016-09-26T13:37:32Z

hal/hal/trng_api.h

+ */
+int trng_get_bytes(trng_t *obj, uint8_t *output, size_t length, size_t *output_length);
+
+/** Get minimum entropy bits per call of the function get_bytes


This function needs to be removed as we're deferring the feature to Q4.

simonbutcher · 2016-09-26T13:41:24Z

features/mbedtls/mbed_trng.c

@@ -0,0 +1,29 @@
+/* mbed Microcontroller Library


This file is floating around in the mbed TLS root directory. Could we create a directory, mbed-os/features/mbedtls/platform for mbed OS specific code related to mbed TLS?

platform will do . This needs also rebase, so I'll do changes, and rebase on top of master.

0xc0170 · 2016-09-26T15:10:02Z

Rebased.

@sbutcher-arm : minimum entropy function was removed, and mbed_trng.c moved to platform folder.

mbed-bot · 2016-09-27T07:57:15Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 961

Build failed!

Otherwise it's implementation specific, IAR fails to compile.

MBEDTLS_ENTROPY_HARDWARE_ALT will be defined via config in mbedtls, the mbed wrapper should use DEVICE_TRNG.

0xc0170 · 2016-09-27T08:22:29Z

All rebased again (while rebasing the last 24 hours, I lost some of my work thus those failues, I resolved them again). Will trigger morph test once the basic checks are done

yanesca · 2016-09-27T08:56:55Z

+1

0xc0170 · 2016-09-27T09:06:16Z

/morph test

mbed-bot · 2016-09-27T10:40:46Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 963

All builds and test passed!

0xc0170 · 2016-09-27T10:57:35Z

Tests all green, ready for merging

@andresag01 Please confirm that mbedtls tests are working with this changeset

andresag01 · 2016-09-27T11:03:51Z

@0xc0170 I have tested this change together with #2716 and Mbed-TLS/mbedtls#615 and it seems to work correctly. However, it would be ideal if #2716 is reviewed and approved and Mbed-TLS/mbedtls#615 is merged before this PR is merged.

It has disappeeared with #2765

0xc0170 added the needs: review label Sep 21, 2016

simonbutcher reviewed Sep 21, 2016

View reviewed changes

simonbutcher suggested changes Sep 21, 2016

View reviewed changes

andresag01 reviewed Sep 21, 2016

View reviewed changes

0xc0170 force-pushed the dev_rng_hal branch from 1ed1dd6 to 9ed82d6 Compare September 21, 2016 16:34

sg- reviewed Sep 22, 2016

View reviewed changes

sg- added needs: work and removed needs: review labels Sep 22, 2016

0xc0170 force-pushed the dev_rng_hal branch from 9ed82d6 to 7803ddd Compare September 22, 2016 07:38

0xc0170 added needs: review needs: work and removed needs: work labels Sep 22, 2016

0xc0170 force-pushed the dev_rng_hal branch from 7803ddd to b9f34ad Compare September 22, 2016 08:42

andresag01 reviewed Sep 22, 2016

View reviewed changes

yanesca reviewed Sep 22, 2016

View reviewed changes

0xc0170 force-pushed the dev_rng_hal branch 3 times, most recently from 7bc695a to 5c09ba7 Compare September 22, 2016 12:31

yanesca reviewed Sep 22, 2016

View reviewed changes

simonbutcher reviewed Sep 26, 2016

View reviewed changes

0xc0170 force-pushed the dev_rng_hal branch from fc19adc to cba85cc Compare September 26, 2016 14:31

0xc0170 added 3 commits September 27, 2016 08:51

RNG - rename rng_get_numbers to rng_get_bytes

e8ca16d

RNG - fix warnings due to obj not used for some targets

a225baf

HAL - rng nuvoton cleanup code style

da1b423

0xc0170 force-pushed the dev_rng_hal branch from bc0e20a to 537ccbb Compare September 27, 2016 08:00

0xc0170 added 8 commits September 27, 2016 09:13

HAL - RNG rename to TRNG

ea1041e

TRNG - remove set seed function

9048113

TRNG - protect HAL implementation if DEVICE_TRNG is not defined

f8c6c23

HAL TRNG - add dummy variable to empty structs

48544fc

Otherwise it's implementation specific, IAR fails to compile.

TRNG HAL - fix length doc wording for get_bytes

88b2220

mbedtls - move TRNG mbed impl into platform folder

1f8da7d

targets - add TRNG device_has to STM32F7 targets

ef58562

mbedtls trng - remove MBEDTLS_ENTROPY_HARDWARE_ALT

1b95c67

MBEDTLS_ENTROPY_HARDWARE_ALT will be defined via config in mbedtls, the mbed wrapper should use DEVICE_TRNG.

0xc0170 force-pushed the dev_rng_hal branch from 537ccbb to 1b95c67 Compare September 27, 2016 08:20

0xc0170 added ready for merge and removed needs: CI labels Sep 27, 2016

sg- merged commit b67e1f7 into ARMmbed:master Sep 27, 2016

sg- added release-version: 5.2.0 and removed ready for merge labels Sep 27, 2016

This was referenced Sep 28, 2016

HEXIWEAR: Enable the entropy collector for use in mbed TLS #2526

Merged

STM32 hw entropy #2611

Merged

jeromecoutant mentioned this pull request Nov 4, 2016

NUCLEO_F410RB: Add I2C_ASYNCH capability #3198

Merged

adbridge pushed a commit that referenced this pull request Nov 10, 2016

NUCLEO_F410RB: Add I2C_ASYNCH capability

36740a1

It has disappeeared with #2765

adbridge pushed a commit that referenced this pull request Nov 18, 2016

NUCLEO_F410RB: Add I2C_ASYNCH capability

2bc0139

It has disappeeared with #2765


		#if defined(MBEDTLS_ENTROPY_HARDWARE_ALT) && defined(DEVICE_RNG)

		int mbedtls_hardware_poll( void data, unsigned char output, size_t len, size_t *olen ) {


		#if DEVICE_RNG

		/** RNG HAL structure. rng_s is declared in the target's HAL


		#include "hal/rng_api.h"

		#if defined(MBEDTLS_ENTROPY_HARDWARE_ALT) && defined(DEVICE_RNG)


		#if DEVICE_TRNG

		/** tRNG HAL structure. trng_s is declared in the target's HAL

		int trng_get_bytes(trng_t obj, uint8_t output, size_t length, size_t *output_length);

		/*@}/

RNG HAL addition #2765

RNG HAL addition #2765

Uh oh!

Conversation

0xc0170 commented Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Status

Todos

Uh oh!

simonbutcher Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simonbutcher Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simonbutcher Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simonbutcher Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simonbutcher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

0xc0170 commented Sep 21, 2016 •

edited

Loading

simonbutcher Sep 21, 2016 •

edited

Loading

simonbutcher Sep 21, 2016 •

edited

Loading

simonbutcher Sep 21, 2016 •

edited

Loading

simonbutcher Sep 21, 2016 •

edited

Loading

0xc0170 Sep 21, 2016 •

edited

Loading

0xc0170 Sep 21, 2016 •

edited

Loading

andresag01 Sep 21, 2016 •

edited

Loading

andresag01 Sep 21, 2016 •

edited

Loading