Driver interface stability promise in Mbed TLS 4.0 #99

New issue

Open

opened 2024-03-21 10:05:30 -05:00 by gilles-peskine-arm · 1 comment

gilles-peskine-arm commented

2024-03-21 10:05:30 -05:00

(Migrated from github.com)

What promises do we make in Mbed TLS 4.0 regarding the stability of driver interfaces? This covers:

Prototype of the C functions that drivers implement.
Provided tooling for generating driver wrappers.
Support of handwritten driver wrappers.

Definition of done: a design decision (the hard part), and document it (the easy part).

What promises do we make in Mbed TLS 4.0 regarding the stability of driver interfaces? This covers: * Prototype of the C functions that drivers implement. * Provided tooling for generating driver wrappers. * Support of handwritten driver wrappers. Definition of done: a design decision (the hard part), and document it (the easy part).

gilles-peskine-arm commented

2024-08-08 11:42:13 -05:00

(Migrated from github.com)

With my Mbed TLS/TF-PSA-Crypto hat, I am uncomfortable promising backward compatibility until we have done three things:

Document the interfaces more precisely. In particular, make sure that it's clear whose responsibility it is to validate what.
Test that the library is validating what the specification says it must validate.
Implement the tooling for generating driver wrappers from JSON.

Given the high bar, I am revising my previous opinion: I don't think we'll have time to do it before the TF-PSA-Crypto 1.0 release. So I'm revising the priority as a COULD, but in all likelihood, this won't happen in time, and we'll have to live with unclear promises for some time longer.

We're strongly considering officializing standardize the driver interface as a PSA interface. If this happens, the PSA Crypto working group will own the interface, not Mbed TLS/TF-PSA-Crypto. This is an argument against promising full backward compatibility of the current interface. With my Mbed TLS/TF-PSA-Crypto hat, I am uncomfortable promising backward compatibility until we have done three things: * Document the interfaces more precisely. In particular, make sure that it's clear whose responsibility it is to validate what. * Test that the library is validating what the specification says it must validate. * Implement the tooling for generating driver wrappers from JSON. Given the high bar, I am revising my previous opinion: I don't think we'll have time to do it before the TF-PSA-Crypto 1.0 release. So I'm revising the priority as a COULD, but in all likelihood, this won't happen in time, and we'll have to live with unclear promises for some time longer.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#99

No description provided.

Rows
Columns