Ensure that num_ops is cleared when manual abort is called, but obviously not
when an operation just completes, and test this.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Move to accumulate ops in context rather than attempting to read straight out
of structures due to structure ops getting reset per operation, and also
issues with _abort clearing internal data. Fix usage of size_t in structures
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Make public the versions of ECSDA sign and verify which return raw signatures
rather than returning ASN.1 encoded signatures, in order to use them for the
internal implemention of psa_sign/verify_hash_interruptible.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Apply the usual parameter name and align the local variables and
comments. This naming diverges from the standard notation, but this is
beneficial as our variable meanings diverge as well and the difference
can help avoiding confusion.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
It is not necessary to save the middle limb upfront as overwriting it is
the desired result: in the first step we are reducing modulo
2^{512+biL}.
Arguably, the original flow is more intuitive and easier to see the idea
behind it.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
The prototype calculated with wrong limb size and not taken into account
the overflow in the shared limb.
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
OID subidentifiers are encoded as follow. For every byte:
* The top bit is 1 if there is another byte to come, 0 if this is the
last byte.
* The other 7 bits form 7 bits of the number. These groups of 7 are
concatenated together in big-endian order.
Overlong encodings are explicitly disallowed by the BER/DER/X690
specification. For example, the number 1 cannot be encoded as:
0x80 0x80 0x01
It must be encoded as:
0x01
Enforce this in Mbed TLS' OID DER-to-string parser.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Pacify Clang >=15 which complained:
```
include/psa/crypto.h:91:23: error: empty paragraph passed to '\retval' command [-Werror,-Wdocumentation]
* \retval #PSA_SUCCESS
~~~~~~~~~~~~~~~~~~~^
```
This commit performs the following systematic replacement:
```
perl -i -0777 -p -e 's/([\\@])(retval +\S+)\n(?! *\*? *([^\n \\*\/]|\\[cp]\b))/$1$2 ${1}emptydescription\n/g' $(git ls-files '*.[hc]' '*.function' '*.jinja')
```
i.e. add an `\emptydescription` argument to `\retval` commands (or
`@retval`, which we don't normally used) that are followed by a single word,
unless the next line looks like it contains text which would be the
description.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since Clang 15, `clang -Wdocumentation` warns about an empty description in
a Doxygen `\retval` command:
```
include/psa/crypto.h:91:23: error: empty paragraph passed to '\retval' command [-Werror,-Wdocumentation]
* \retval #PSA_SUCCESS
~~~~~~~~~~~~~~~~~~~^
```
Ideally `\retval` directives should have a description that describes the
precise meaning of the return value, but we commonly use an empty
description when the return value is a status code and the status code's
description is sufficient documentation.
As a workaround, define a Doxygen command `\emptydescription` that we can
use to make the description source code non-empty, without changing the
appearance. Using the command will be done in a subsequent commit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The first 2 components of an OID are combined together into the same
subidentifier via the formula:
subidentifier = (component1 * 40) + component2
The current code extracts component1 and component2 using division and
modulo as one would expect. However, there is a subtlety in the
specification[1]:
>This packing of the first two object identifier components recognizes
>that only three values are allocated from the root node, and at most
>39 subsequent values from nodes reached by X = 0 and X = 1.
If the root node (component1) is 2, the subsequent node (component2)
may be greater than 38. For example, the following are real OIDs:
* 2.40.0.25, UPU standard S25
* 2.49.0.0.826.0, Met Office
* 2.999, Allocated example OID
This has 2 implications that the current parsing code does not take
account of:
1. The second component may be > 39, so (subidentifier % 40) is not
correct in all circumstances.
2. The first subidentifier (containing the first 2 components) may be
more than one byte long. Currently we assume it is just 1 byte.
Improve parsing code to deal with these cases correctly.
[1] Rec. ITU-T X.690 (02/2021), 8.19.4
Signed-off-by: David Horstmann <david.horstmann@arm.com>
