There are many reasons why a driver might violate the security requirements
for plaintext or ciphertext buffers, so mandate copying.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's a security violation, although it's not clear whether it really needs
to influence the design.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Mostly to reflect this has been implemented, and remove references to
temporary remains from the previous strategy (hash_info, legacy_or_psa)
which would probably be more confusing than helpful at this point.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Latest changes:
- logic about the relationship between curves, key types and algs (8075)
- building without bignum is no longer "coming soon", it's there :)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There was a bit of a race condition between #8041 which introduced the
new entry points, and #8203 which documented the list of entry points.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Now that p256-m is officially a production feature and not just an example,
give it a more suitable name.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
State explicitly the non-requirement that it's ok for psa_destroy_key to
block waiting for a driver.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- Use unique section titles so that there are unique anchors
- Make list style consistent between similar sections
Signed-off-by: Janos Follath <janos.follath@arm.com>
We shouldn't violate the requirement that the key identifier can be
reused. In practice, a key manager may destroy a key that's in use by
another process, and the privileged world containing the key manager and
the crypto service should not be perturbed by an unprivileged process.
With respect to blocking, again, a key manager should not be blocked
indefinitely by an unprivileged application.
These are desirable properties even in the short term.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- the codegen migration document is already a migration document, so
doesn't need the extra warning about work in progress;
- the driver interface can use a link to the more practical guide too.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Some documents about driver describe a state of things that is ahead of
the reality. They already contain a warning about it, but no way to know
that the current reality is; add a pointer to a document that describes
it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
