Error codes for hardware accelerator failures #1303

gilles-peskine-arm · 2018-01-24T10:15:39Z

Add MBEDTLS_ERR_XXX_HW_ACCEL_FAILED error codes for all cryptography
modules where the software implementation can be replaced by a hardware
implementation.

This does not include the individual message digest modules since they
currently have no way to return error codes. That part is done in #1294

This does include the higher-level md, cipher and pk modules since
alternative implementations and even algorithms can be plugged in at
runtime.

[added by mpg]: no backports required, hardware acceleration is a new feature

Internal reference: IOTSSL-2039

RonEld · 2018-01-24T10:42:54Z

While we are working on this, I would also think adding MBEDTLS_ERR_XXX_FEATURE_UNAVAILABLE, for features the HW acceleration doesn't support, such as key size, unsupported curves, etc..
We have suce an error for AES

gilles-peskine-arm · 2018-01-24T10:47:14Z

@RonEld Shouldn't this be a job for the higher-level modules (cipher, md, pk)?

RonEld · 2018-01-24T12:47:10Z

@gilles-peskine-arm I don't think so. IMHO, I am talking about errors that should be returned by the alternative implementations, in case they don't support a specific feature. But, this could wait.

AndrzejKurek · 2018-01-25T11:29:09Z

include/mbedtls/error.h

@@ -75,11 +78,11 @@
 * X509      2   20
 * PKCS5     2   4 (Started from top)
 * DHM       3   9


Didn't adding MBEDTLS_ERR_DHM_HW_ACCEL_FAILED increase the DHM error count by 1?

Indeed. Thanks, fixed.

mpg

Blocker: status of ECJPAKE (either change it or convince me that it's indeed the least bad option).

Minor: redundant counter to update.

mpg · 2018-01-25T11:42:28Z

scripts/generate_errors.pl

-                          "SHA1", "SHA256", "SHA512", "GCM", "THREADING", "CCM" );
-my @high_level_modules = ( "PEM", "X509", "DHM", "RSA", "ECP", "MD", "CIPHER", "SSL",
-                           "PK", "PKCS12", "PKCS5" );
+my @low_level_modules = qw( AES ARC4 ASN1 BASE64 BIGNUM BLOWFISH


Thanks for cleaning up this list! However I'd have preferred a separate commit for the cleanup rather than mixing cleanup and adding new modules to that list. (As far as I'm concerned, don't bother rewriting history for that, just saying for the future.)

You're right, I rushed this through. Since the PR needs updating anyway and it doesn't have a complicated history, I can rewrite the history while I'm at it, if it's ok with you.

Sure, feel free to clean up the history!

mpg · 2018-01-25T12:02:47Z

include/mbedtls/error.h

- * XTEA      1  0x0028-0x0028
+ * AES       4  0x0020-0x0022   0x0023-0x0025
+ * CAMELLIA  3  0x0024-0x0026   0x0027-0x0027
+ * XTEA      1  0x0028-0x0028   0x0029-0x0029


Please update the Nr column from 1 to 2.

mpg · 2018-01-25T12:17:53Z

include/mbedtls/ecjpake.h

@@ -44,6 +44,8 @@
 #include "ecp.h"
 #include "md.h"

+#define MBEDTLS_ERR_ECJPAKE_HW_ACCEL_FAILED               -0x0078  /**< ECJPAKE hardware accelerator failed */


Treating ECJPAKE as a low-level module it inconsistent with the fact that it's built on top of ECP which is considered a high-level module (due to the fact that it build on top of MPI I guess).

Now I realise that in practice that distinction mostly matters because so that we can do this in high-level modules:

ret = some_low_level_function(); if( ret != 0 ) ret += my_high_level_code;

and in practice I don't see than happening here, but it still bothers me to have a low-level module based on a "high-level" one.

Now I also realise we don't have enough spots left for high-level module any more, and so far we've cheated by deciding that modules based on ECP use error codes in the ECP namespace (which is why we have such things as MBEDTLS_ERR_ECP_VERIFY_FAILED rather than having it in ECDSA. So far most errors returned by ECJPAKE functions live in the ECP namespace too.

So I understand there may not be any good solution here in our current system, but I'm not really happy with adding low-level error codes fro ECJPAKE.

Note: what I'm suggesting is that alternative implementation of ECJPAKE use the ECP error code, just like alt ECDH implementations do.

Ugh. That's a good point. Indeed, it's annoying. @hanno-arm ECJPAKE_HW_ACCEL_FAILED is to complement #1304 . What do you think of Manuel's proposal to use ECP_HW_ACCEL_FAILED?

@gilles-peskine-arm @mpg I support Manuel's proposal of using ECP_HW_ACCEL_FAILED. I think that while perhaps not optimal, having modules based on ECP use error codes from the ECP namespace -- thereby effectively collapsing the namespaces from there because our allocation of error codes doesn't allow to step 'one level up' -- is still cleaner than using low-level codes.

@sbutcher-arm verbally approved using ECP_HW_ACCEL_FAILED for ECJPAKE, so I'll withdraw the ECJPAKE_HW_ACCEL_FAILED error code.

gilles-peskine-arm · 2018-01-25T22:38:45Z

@mpg @hanno-arm @AndrzejKurek @RonEld I rewrote the history to split out the list sorting in generate_errors.pl, remove the error.h count fixups, and remove the addition of an ECJPAKE error code. The old history is at https://github.com/gilles-peskine-arm/mbedtls/tree/err_hw_failed-1

AndrzejKurek · 2018-01-26T10:43:15Z

Looks fine to me.

hanno-becker · 2018-01-26T16:02:58Z

include/mbedtls/aes.h

 #define MBEDTLS_ERR_AES_FEATURE_UNAVAILABLE               -0x0023  /**< Feature not available, e.g. unsupported AES key size. */
+#define MBEDTLS_ERR_AES_HW_ACCEL_FAILED                   -0x0025  /**< AES hardware accelerator failed */


Dot missing at the end, here and in the rest of the PR.

I amended and force-pushed a version with dots at the end. The previous commit is at https://github.com/gilles-peskine-arm/mbedtls/tree/err_hw_failed-2

hanno-becker

With the recent changes to the documentation, all Doxygen comments should end with a dot, which is not the case for the documentation this PR adds. Apart from that, the changes look good to me.

Add MBEDTLS_ERR_XXX_HW_ACCEL_FAILED error codes for all cryptography modules where the software implementation can be replaced by a hardware implementation. This does not include the individual message digest modules since they currently have no way to return error codes. This does include the higher-level md, cipher and pk modules since alternative implementations and even algorithms can be plugged in at runtime.

gilles-peskine-arm added enhancement mbed TLS team needs-review Every commit must be reviewed by at least two team members, labels Jan 24, 2018

gilles-peskine-arm requested a review from simonbutcher January 24, 2018 10:15

gilles-peskine-arm mentioned this pull request Jan 24, 2018

Ctr drbg #1196

Merged

4 tasks

gilles-peskine-arm mentioned this pull request Jan 24, 2018

MD API changes to introduce int return codes (2.7) #1294

Merged

gilles-peskine-arm requested a review from mpg January 24, 2018 12:01

gilles-peskine-arm mentioned this pull request Jan 24, 2018

Add support for alternative ECJPAKE implementation #1304

Merged

simonbutcher approved these changes Jan 24, 2018

View reviewed changes

Patater requested a review from AndrzejKurek January 25, 2018 11:00

AndrzejKurek suggested changes Jan 25, 2018

View reviewed changes

AndrzejKurek approved these changes Jan 25, 2018

View reviewed changes

mpg requested changes Jan 25, 2018

View reviewed changes

Sort list to make things easier to find

9214327

gilles-peskine-arm force-pushed the err_hw_failed branch from 1b5045c to 728197b Compare January 25, 2018 22:36

hanno-becker reviewed Jan 26, 2018

View reviewed changes

hanno-becker approved these changes Jan 26, 2018

View reviewed changes

gilles-peskine-arm force-pushed the err_hw_failed branch from 728197b to 7ecab3d Compare January 26, 2018 16:57

mpg approved these changes Jan 29, 2018

View reviewed changes

mpg added approved Design and code approved - may be waiting for CI or backports and removed needs-review Every commit must be reviewed by at least two team members, labels Jan 29, 2018

Patater merged commit 7ecab3d into Mbed-TLS:development Jan 29, 2018

hanno-becker mentioned this pull request Feb 2, 2018

M487: Support ECP H/W accelerator ARMmbed/mbed-os#5812

Merged

		#define MBEDTLS_ERR_AES_FEATURE_UNAVAILABLE -0x0023 /*< Feature not available, e.g. unsupported AES key size. /
		#define MBEDTLS_ERR_AES_HW_ACCEL_FAILED -0x0025 /*< AES hardware accelerator failed /

Error codes for hardware accelerator failures #1303

Error codes for hardware accelerator failures #1303

Uh oh!

Conversation

gilles-peskine-arm commented Jan 24, 2018 • edited by mpg Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RonEld commented Jan 24, 2018

Uh oh!

gilles-peskine-arm commented Jan 24, 2018

Uh oh!

RonEld commented Jan 24, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mpg left a comment • 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!

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!

gilles-peskine-arm commented Jan 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AndrzejKurek commented Jan 26, 2018

Uh oh!

hanno-becker Jan 26, 2018 • 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!

hanno-becker left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gilles-peskine-arm commented Jan 24, 2018 •

edited by mpg

Loading

mpg left a comment •

edited

Loading

gilles-peskine-arm commented Jan 25, 2018 •

edited

Loading

hanno-becker Jan 26, 2018 •

edited

Loading