Pkcs11 login #3750

jenswi-linaro · 2020-04-14T15:25:15Z

No description provided.

Sync with PKCS11 TA API update from [1] for authentication related commands. Link: [1] OP-TEE/optee_os#3750 Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

etienne-lms

for commit "ta: pkcs11: helper for GPD TEE to PKCS#11 status conversion"

etienne-lms · 2020-04-14T15:40:08Z

ta/pkcs11/src/pkcs11_helpers.c

+	case TEE_ERROR_SHORT_BUFFER:
+		return PKCS11_CKR_BUFFER_TOO_SMALL;
+
+	case TEE_ERROR_MAC_INVALID:


for info: TEE_ERROR_SIGNATURE_INVALID from TEE_AsymmetricVerifyDigest() also matches PKCS11_CKR_SIGNATURE_INVALID.

OK, I'll add that here.

etienne-lms

for commit "ta: pkcs11: helpers for PIN hashing"

etienne-lms · 2020-04-14T15:54:19Z

ta/pkcs11/src/persistent_token.c

+
+	res = TEE_AllocateOperation(&oh, TEE_ALG_SHA256, TEE_MODE_DIGEST, 0);
+	if (res)
+		return PKCS11_CKR_GENERAL_ERROR;


don't you prefer to report at least of out-of-memory status when allocation fails for that.

OK, I'll update with tee2pkcs_error().

etienne-lms

for commit "ta: pkcs11: update PIN fields in struct token_persistent_main"
Reviewed-by: Etienne Carriere <[email protected]>

etienne-lms

for commit "ta: pkcs11: update PIN fields in struct token_persistent_main"
Reviewed-by: Etienne Carriere <[email protected]>

etienne-lms

for commit "ta: pkcs11: implement command PKCS11_CMD_INIT_TOKEN":
In commit message: s/implement/implements/

etienne-lms · 2020-04-14T16:03:52Z

ta/pkcs11/src/pkcs11_token.c

+
+	serialargs_init(&ctrlargs, ctrl->memref.buffer, ctrl->memref.size);
+
+	rc = serialargs_get(&ctrlargs, &token_id, sizeof(uint32_t));


From PKCS11 spec, there are precedence requirement on some (very few) return values.
Invalid slot ID (or token ID, same) is one of them.

You can find below a suggestion to factorize this with a friendly serialargs_get_session() helper function:
etienne-lms@6a1e6d9

PKCS11_CKR_SLOT_ID_INVALID, does not take precedence over any other error code (see 5.1.6 All other Cryptoki function return values).
The precedence rule (as I understand it) only is applicable if there's multiple competing errors. So if unpacking of arguments fail, we return PKCS11_CKR_ARGUMENTS_BAD, there's no other competing error code at this stage.

I'll move and update the pin_size check below though. I guess it makes sense to check the arguments in the order they were supplied to C_InitToken().

You're right, sorry. I mixed up with the session handle that should take precedence (CKR_SESSION_HANDLE_INVALID).

I think my comment could apply to the commits where session_handle is read from the client arguments.

etienne-lms · 2020-04-14T16:04:58Z

ta/pkcs11/src/pkcs11_token.c

+
+	token = get_token(token_id);
+	if (!token)
+		return PKCS11_CKR_SLOT_ID_INVALID;


see comment above.

etienne-lms · 2020-04-14T16:05:58Z

ta/pkcs11/src/pkcs11_token.c

+		return PKCS11_CKR_PIN_LOCKED;
+	}
+
+	/* Check  there's no open session on this token */


double space chars.

etienne-lms · 2020-04-14T16:09:04Z

ta/pkcs11/src/pkcs11_token.c

+		if (rc)
+			return rc;
+
+		update_persistent_db(token);


can't this operation fail?

Commit "ta: pkcs11: helper to update token persistent database" should be placed before this commit in the series.

No it can't fail, the TA panics instead since continueing from here could be a security problem.

true, sorry. I made this comment before looking at the implementation 👎

etienne-lms · 2020-04-14T16:15:52Z

ta/pkcs11/src/pkcs11_token.c

+
+		if (token->db_main->so_pin_count == 6)
+			token->db_main->flags |= PKCS11_CKFT_SO_PIN_FINAL_TRY;
+		if (token->db_main->so_pin_count == 7)


Maybe the max number of attempts should be configurable.

Agree, I'll fix.

etienne-lms · 2020-04-14T16:22:21Z

ta/pkcs11/src/pkcs11_token.c

+	update_persistent_db(token);
+
+	label[PKCS11_TOKEN_LABEL_SIZE] = '\0';
+	IMSG("PKCS11 token %"PRIu32": initialized \"%s\"", token_id, label);


Label is UTF8 so not sure IMSG() is able to print it.

OK, I'll remove it.

etienne-lms

for commit "ta: pkcs11: implement command PKCS11_CMD_INIT_PIN':
in commit log: s/implement/implments/, 2 spaces before "Security Officer", missing terminal dot.

etienne-lms · 2020-04-14T16:28:37Z

ta/pkcs11/src/pkcs11_token.c

+	return PKCS11_CKR_OK;
+}
+
+/* ctrl=[session-handle][pin-size]{pin-arrays], in=unused, out=unused */


remove comment

etienne-lms · 2020-04-14T16:39:32Z

ta/pkcs11/src/pkcs11_token.c

+
+	serialargs_init(&ctrlargs, ctrl->memref.buffer, ctrl->memref.size);
+
+	rc = serialargs_get(&ctrlargs, &session_handle, sizeof(uint32_t));


minor: prefer here sizeof(uint32_t) or sizeof(session_handle)?

In this case I prefer sizeof(uint32_t) since it's a bit easier to double check the ABI.

etienne-lms

for commit "ta: pkcs11: implement command PKCS11_CMD_SET_PIN":
in commit log: s/implement/implements/

etienne-lms · 2020-04-14T16:42:27Z

ta/pkcs11/include/pkcs11_ta.h

+	 * [out] memref[0] = 32bit return code, enum pkcs11_rc
+	 *
+	 * This command relates to the PKCS#11 API function
+	 * C_CloseAllSessions().


s/C_CloseAllSessions/C_SetPIN.

etienne-lms · 2020-04-14T16:44:32Z

ta/pkcs11/src/pkcs11_token.c

+	return PKCS11_CKR_OK;
+}
+
+/* ctrl=[session][old-size]{old-pin][pin-size]{pin], in=unused, out=unused */


remove comment

etienne-lms · 2020-04-14T16:47:04Z

ta/pkcs11/src/pkcs11_token.c

+	TEE_Param *ctrl = params;
+	uint32_t pin_size = 0;
+	void *old_pin = NULL;
+	void *pin = NULL;


beautiful trapezium :)

etienne-lms · 2020-04-14T16:48:29Z

ta/pkcs11/src/pkcs11_token.c

+	enum pkcs11_rc rc = PKCS11_CKR_OK;
+
+	if (!token->db_main->user_pin_salt ||
+	    !(token->db_main->flags & PKCS11_CKFT_USER_PIN_INITIALIZED))


need to check both? info is redundant.

I'll remove the flags test.

etienne-lms · 2020-04-14T16:56:43Z

ta/pkcs11/src/pkcs11_token.c

+	struct ck_token *token = session->token;
+	enum pkcs11_rc rc = PKCS11_CKR_OK;
+
+	/* Note: intentional return code USER_PIN_NOT_INITIALIZED */


C_SetPIN() should not return CKR_USER_PIN_NOT_INITIALIZED. Is it because test below should be happen that this intentionally returns such status? Why not an assertion or a straight panic?

OK, I'll assert.

etienne-lms · 2020-04-14T16:57:38Z

ta/pkcs11/src/pkcs11_token.c

+	}
+
+	if (token->db_main->flags & (PKCS11_CKFT_SO_PIN_COUNT_LOW |
+					PKCS11_CKFT_SO_PIN_FINAL_TRY)) {


prefer indent to opening parenthesis.

etienne-lms

for commit "ta: pkcs11: helper to update token persistent database"

etienne-lms · 2020-04-14T17:12:14Z

ta/pkcs11/src/persistent_token.c

+
+	res = open_db_file(token, &db_hdl);
+	if (res) {
+		EMSG("Failed to open token persisten db: %#"PRIx32, res);


s/persisten/persisent/

ditto below.

Or persistent even :-)

etienne-lms · 2020-04-14T17:12:36Z

ta/pkcs11/src/persistent_token.c

+
+	TEE_CloseObject(db_hdl);
+
+	return tee2pkcs_error(res);


etienne-lms

for commit "ta: pkcs11: implement commands PKCS11_CMD_LOGIN/_LOGOUT"

etienne-lms · 2020-04-14T17:14:10Z

ta/pkcs11/src/pkcs11_token.c

+	}
+}
+
+/* ctrl=[session][user_type][pin-size]{pin], in=unused, out=unused */


remove comment

etienne-lms · 2020-04-14T17:23:17Z

ta/pkcs11/src/pkcs11_token.c

+		 * This is the point where we could check if another client
+		 * has another user or SO logged in. Currently we don't
+		 * care.
+		 */


why not checking that now? We could parse the client list pkcs11_client_list for that.

The spec says:

CKR_USER_TOO_MANY_TYPES: An attempt was made to have more distinct users simultaneously logged into the token than the token and/or library permits. For example, if some application has an open SO session, and another application attempts to log the normal user into a session, the attempt may return this error. It is not required to, however. Only if the simultaneous distinct users cannot be supported does C_Login have to return this value. Note that this error code generalizes to true multi-user tokens.

So we are permitted to skip this check, I don't see any harm in skipping it. The comment should be more clear on this though. I'll update that.

Ok for nit dealing with CKR_USER_TOO_MANY_TYPES.
But maybe another client (client application) has open sessions towards the token. These session should be considered as well as the session owned by the current client.

I think made proto made a shortcut, returning CKR_USER_TOO_MANY_TYPES if other clients were found on same token instead of properly handling their sessions state.

Please crosscheck with "2.6.8 Example of use of sessions" in "PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40".

To me it seems that clients are quite independent of each other when it comes to logins.

You're right. Discard my comment.

etienne-lms · 2020-04-14T17:24:35Z

ta/pkcs11/src/pkcs11_token.c

+	return rc;
+}
+
+/* ctrl=[session], in=unused, out=unused */


remove comment

jenswi-linaro · 2020-04-15T08:56:20Z

Update

etienne-lms

Following commit "ta: pkcs11: update PIN fields in struct token_persistent_main", could you add a commit to remove init_pin_keys(), open_pin_file() and get_pin_file_name() local functions from persistent_token.c?

etienne-lms · 2020-04-15T12:37:03Z

ta/pkcs11/src/pkcs11_token.c

+
+	update_persistent_db(token);
+
+	label[PKCS11_TOKEN_LABEL_SIZE] = '\0';


can remove this, and:

- char label[PKCS11_TOKEN_LABEL_SIZE + 1] = { 0 }; + char label[PKCS11_TOKEN_LABEL_SIZE] = { 0 };

etienne-lms · 2020-04-15T12:56:38Z

@wamserma, @Emantor, @ricardosalveti could you have a look at this P-R and related OP-TEE/optee_client#205 and OP-TEE/optee_test#418?

jenswi-linaro · 2020-04-16T06:19:43Z

I'm going to squash the commits and rebase on master to make it easier to review.

jenswi-linaro · 2020-04-16T06:31:16Z

Updated and rebased on master

Emantor

Acked-by: Rouven Czerwinski <[email protected]>

Emantor · 2020-04-16T08:32:16Z

ta/pkcs11/src/pkcs11_token.c

+	if (rc)
+		return rc;
+
+	IMSG("PKCS11 session %"PRIu32": set PIN", session_handle);


Maybe add an equivalent IMSG for the SO case above?

I'll add one.

Sync with PKCS11 TA API update from [1] for authentication related commands. Link: [1] OP-TEE/optee_os#3750 Reviewed-by: Rouven Czerwinski <[email protected] Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

Sync with PKCS11 TA API update from [1] for authentication related commands. Link: [1] OP-TEE/optee_os#3750 Reviewed-by: Rouven Czerwinski <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

Introduce helper function pkcs2tee_error() for the several TEE Core Internal APIs called for which return value needs to be reported to caller in PKCS#11 return code format. The function returns PKCS11_CKR_GENERAL_ERROR for TEE_Result values that do not strictly match a PKCS#11 return code. Acked-by: Rouven Czerwinski <[email protected]> Co-developed-by: Etienne Carriere <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

Adds helpers to hash PIN and to verify the hash of a PIN. The PIN is hashed together with user type and a generated salt. A used salt never takes the value 0 so that can be used to tell if a PIN is set. Acked-by: Rouven Czerwinski <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

Replaces the fields use to keep track of encrypted PINs with fields to keep track of hashed PINs instead. Acked-by: Rouven Czerwinski <[email protected]> Reviewed-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

update_persistent_db() updates the persistent database or panics on failure. Acked-by: Rouven Czerwinski <[email protected]> Co-developed-by: Etienne Carriere <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

PKCS11_CMD_INIT_TOKEN implements C_InitToken() client API function that is in charge of initializing the Security Officer login PIN if not already done and destroy objects that can be. As objects are not yet supported in the TA, this later feature is not implemented. Acked-by: Rouven Czerwinski <[email protected]> Co-developed-by: Etienne Carriere <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

PKCS11_CMD_INIT_PIN implements C_InitPIN() client API function that is in charge of initializing the normal user login PIN. Security Officer must be logged to current session in order to call this function Acked-by: Rouven Czerwinski <[email protected]> Co-developed-by: Etienne Carriere <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

PKCS11_CMD_SET_PIN implements C_SetPIN() client API function that is in charge of modifying a login PIN. Acked-by: Rouven Czerwinski <[email protected]> Co-developed-by: Etienne Carriere <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

Implements login/logout support. Acked-by: Rouven Czerwinski <[email protected]> Co-developed-by: Etienne Carriere <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

PINs are hashed with a salt instead of being encrypted with a secret key. So remove the now unused management of these secret keys. Acked-by: Rouven Czerwinski <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

jenswi-linaro · 2020-04-16T12:37:07Z

Squashed and tag applied

Sync with PKCS11 TA API update from [1] for authentication related commands. Link: [1] OP-TEE/optee_os#3750 Reviewed-by: Rouven Czerwinski <[email protected]> Signed-off-by: Etienne Carriere <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

wamserma

Oh, you merged before I finished reviewing..

wamserma · 2020-04-16T08:35:30Z

ta/pkcs11/include/pkcs11_ta.h

+	 *
+	 * [in]  memref[0] = [
+	 *              32bit slot ID,
+	 *              32bit PIN length,


align description of arguments with those of remaining pin functions, e.g. PIN length -> PIN byte size

wamserma · 2020-04-16T08:35:54Z

ta/pkcs11/include/pkcs11_ta.h

+	 *              32bit session handle,
+	 *              32bit old PIN byte size,
+	 *              32bit new PIN byte size,
+	 *              byte array: PIN data,


old PIN data

wamserma · 2020-04-16T08:39:37Z

ta/pkcs11/include/pkcs11_ta.h

+	PKCS11_CMD_SET_PIN = 12,
+
+	/*
+	 * PKCS11_CMD_LOGIN - Initialize user PIN


-> PKCS11_CMD_LOGIN - Log into token

wamserma · 2020-04-16T09:49:59Z

ta/pkcs11/src/persistent_token.c

-
-	if (res == TEE_SUCCESS)
-		DMSG("PIN key found");
+	res = TEE_AllocateOperation(&oh, TEE_ALG_SHA256, TEE_MODE_DIGEST, 0);


SHA256 might not be the best choice here. Ideally it would be Argon2, but to do with what we have we could at least use PBKDF2 unless this was specifically excluded from OP-TEE in conf.mk.
This is a second line of defence in case RPMB-based retry-counters and/or secure storage are not available.

Ah nice, I checked this to against the TEE specification, but did conclude that the specifications best hash function for this was SHA256 (or SHA512). As OP-TEE defines PBKDF2, we should definitely switch to it.

Agreed, with sensible parameters for iteration count. What to do if PBKDF2 is deactivated from the config? Also deactivate PKCS#11 support or fall back to SHA256 (with more than one iteration)?

I think we can depend on PBKDF2 being available.

wamserma · 2020-04-16T10:04:51Z

ta/pkcs11/src/persistent_token.c

-		res = TEE_AllocateTransientObject(TEE_TYPE_AES, 128, &hdl);
-		if (res)
-			TEE_Panic(0);
+enum pkcs11_rc hash_pin(enum pkcs11_user_type user, const uint8_t *pin,


I got a bit confused by the naming of the function. With hash_pin one would expect to get the same hash for a given set of inputs (and this function being used in the verification step), but this function also generates a fresh salt.
Maybe rename to init_pin_hash.

wamserma · 2020-04-16T10:10:52Z

ta/pkcs11/src/persistent_token.c

-			TEE_Panic(0);
+	TEE_GenerateRandom(&s, sizeof(s));
+	if (!s)
+		s++;


This creates a slight bias towards a salt of value 1 and looks a bit like a weird tacked-on fix. Is there a specific reason for excluding the value 0? If so, why not

uint32_t s = 0; while (s == 0) { TEE_GenerateRandom(&s, sizeof(s)); }

for better readability.
If one also needs to cover the case of a broken GenerateRandom that always returns 0, add a constant in the loop body.

A salt of 0 indicates that there is no salt set AFAIR from the rest of the code. I think the bias would be small, but agree that your implementation for this would be cleaner. Do you want to create a PR against current master with your fixes?

From reading the rest of the code a salt of 0 indicates the user PIN has not yet been initialised.

wamserma · 2020-04-16T10:58:10Z

ta/pkcs11/src/persistent_token.c


-	if (res)
-		TEE_Panic(res);
+	if (buf_compare_ct(tmp_hash, hash, TEE_MAX_HASH_SIZE))


Use consttime_memcmp, see https://github.com/OP-TEE/optee_os/blob/3.8.0/lib/libutils/ext/include/string_ext.h#L27

wamserma · 2020-04-16T11:02:19Z

ta/pkcs11/src/persistent_token.c


-	TEE_CloseObject(key_hdl);
+	return rc;


Execution flow arrives here only with rc being 0. But imho explicitly setting the OK in the else path of the hash-comparison would be clearer.

wamserma · 2020-04-16T11:06:14Z

ta/pkcs11/src/pkcs11_token.h

@@ -39,6 +40,8 @@ struct pkcs11_client;
 #define PKCS11_MAX_USERS		2
 #define PKCS11_TOKEN_PIN_SIZE_MAX	128
 #define PKCS11_TOKEN_PIN_SIZE_MIN	10
+#define PKCS11_TOKEN_SO_PIN_COUNT_MAX	7
+#define PKCS11_TOKEN_USER_PIN_COUNT_MAX	7


tabs/spacing

wamserma · 2020-04-16T11:07:33Z

ta/pkcs11/src/pkcs11_token.h

@@ -47,22 +50,22 @@ struct pkcs11_client;
 * @label - pkcs11 formatted token label, set by client
 * @flags - pkcs11 token flags
 * @so_pin_count - counter on security officer login failure
- * @so_pin_size - byte size of the provisioned SO PIN
- * @so_pin - stores the SO PIN
+ * @so_pin_salt - stores salt in hash of SO PIN, 0 if not set


stores salt for hash... (in is ambiguous: could also mean the salt is prepended to the hash instead of being stored in its own field)

wamserma

Part 2 of my review.

wamserma · 2020-04-16T14:55:04Z

ta/pkcs11/src/pkcs11_token.c

+	struct ck_token *token = session->token;
+	enum pkcs11_rc rc = PKCS11_CKR_OK;
+
+	assert(token->db_main->flags & PKCS11_CKFT_TOKEN_INITIALIZED);


As far as I understand the specification, we could also return CKR_OPERATION_NOT_INITIALIZED here instead of using the assert statement.

This "can't happen", that flag is always checked before calling this function.

So it is either dead code and can be removed or the abort is desired and a TEE_Panic would be the proper way to do this.

All asserts are supposed to be dead code.

wamserma · 2020-04-16T15:05:59Z

ta/pkcs11/src/pkcs11_token.c

+
+	TAILQ_FOREACH(sess, &client->session_list, link) {
+		if (sess->token != session->token)
+			continue;


This does assume that we eventually find the right one. Otherwise simply the last session in the list is used.
Maybe we should add

if (sess->token != session->token) return;

here to avoid manipulating the state of a wrong session (and possibly elevate privileges)

We're not just looking for one session, we're looking for all sessions for the client on this token.

My bad. Got the scope of the FOREACH wrong while reading.

wamserma · 2020-04-16T15:06:47Z

ta/pkcs11/src/pkcs11_token.c

+	TAILQ_FOREACH(sess, &client->session_list, link) {
+		if (sess->token != session->token)
+			continue;
+


Same as above.

wamserma · 2020-04-16T15:07:08Z

ta/pkcs11/src/pkcs11_token.c

+	TAILQ_FOREACH(sess, &client->session_list, link) {
+		if (sess->token != session->token)
+			continue;
+


Same as above.

jforissier · 2020-04-16T15:30:13Z

Oh, you merged before I finished reviewing..

😮 sorry about that. You're right, I should leave a bit more time for reviewers...

But it should not prevent us from addressing your comments, let's address them in a new PR if you don't mind, @jenswi-linaro?

jenswi-linaro · 2020-04-16T15:32:13Z

@wamserma, feel free to raise PR to fix what you think need to be fixed.

wamserma · 2020-04-16T16:30:56Z

@jforissier It's ok. There were no super-critical comments and I don't want to slow down anything.
@jenswi-linaro A few of the points need discussion before a new PR can solve the remainders.

jenswi-linaro mentioned this pull request Apr 14, 2020

Pkcs11 login OP-TEE/optee_client#205

Merged

etienne-lms reviewed Apr 14, 2020

View reviewed changes

etienne-lms reviewed Apr 15, 2020

View reviewed changes

jenswi-linaro force-pushed the pkcs11_login branch from 71545e8 to 52b5652 Compare April 16, 2020 06:31

Emantor approved these changes Apr 16, 2020

View reviewed changes

jenswi-linaro added 9 commits April 16, 2020 14:35

ta: pkcs11: remove unused PIN encryption key functions

7b74833

PINs are hashed with a salt instead of being encrypted with a secret key. So remove the now unused management of these secret keys. Acked-by: Rouven Czerwinski <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>

jenswi-linaro force-pushed the pkcs11_login branch from 54dbf79 to 7b74833 Compare April 16, 2020 12:36

jforissier merged commit aa442cd into OP-TEE:master Apr 16, 2020

jenswi-linaro deleted the pkcs11_login branch April 16, 2020 14:13

wamserma suggested changes Apr 16, 2020

View reviewed changes

wamserma reviewed Apr 16, 2020

View reviewed changes

jenswi-linaro mentioned this pull request Apr 23, 2020

ta: pkcs11: factorize session handle argument handling #3781

Merged


		serialargs_init(&ctrlargs, ctrl->memref.buffer, ctrl->memref.size);

		rc = serialargs_get(&ctrlargs, &token_id, sizeof(uint32_t));


		serialargs_init(&ctrlargs, ctrl->memref.buffer, ctrl->memref.size);

		rc = serialargs_get(&ctrlargs, &session_handle, sizeof(uint32_t));


		update_persistent_db(token);

		label[PKCS11_TOKEN_LABEL_SIZE] = '\0';

Pkcs11 login #3750

Pkcs11 login #3750

Conversation

jenswi-linaro commented Apr 14, 2020

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jenswi-linaro commented Apr 15, 2020

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms commented Apr 15, 2020

jenswi-linaro commented Apr 16, 2020

jenswi-linaro commented Apr 16, 2020

Emantor left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jenswi-linaro commented Apr 16, 2020

Emantor Apr 16, 2020 •

edited

Loading