Hi, While working on updating mbedtls to v3.0, I saw that the internal fields in MBEDTLS have been made private. ( ref- herehttps://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guide.md#most-structure-fields-are-now-private). It says there and I quote "As a last resort, you can access the field foo of a structure bar by writing bar.MBEDTLS_PRIVATE(foo). Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.”
I just wanted to know if there is any alternative solution to this, rather than using `MBEDTLS_PRIVATE` everywhere. I know the next release of mbedtls probably plans to fix this with appropriate solution. But we wanted to push out our feature branch As early as possible. I saw in the PRhttps://github.com/zephyrproject-rtos/zephyr/pull/37753 in zephyr RTOS about updating to mbedtls-3.0. They have just added this linehttps://github.com/ceolin/zephyr/blob/5bf3128a9703561e578651218f5bcdafb96f87ed/subsys/net/lib/sockets/sockets_tls.c#L32
#if !defined(MBEDTLS_ALLOW_PRIVATE_ACCESS) #define MBEDTLS_ALLOW_PRIVATE_ACCESS # endif
Is this an alternative solution to using `MBEDTLS_PRIVATE` for accessing a private field. If yes, can somebody please point me to respective document as this would greatly reduce our code-changes.
I understand there is some discussion going on in mbedtls about this change, and appropriate getter-setter functions shall be provided. But we wanted to push out out feature branch for early testing. Thanks and Regards, Aditya
Hi Aditya,
As you've discovered, MBEDTLS_ALLOW_PRIVATE_ACCESS gives access to all private fields. We have deliberately not documented it because it's an internal implementation detail: it was intended only to allow access to all private fields from inside the Mbed TLS library code, and in invasive tests. It may change at any time without warning.
I do not recommend using it. You'll save some time now, but you'll have a harder time later when private fields change and your code might still compile, but have bugs due to semantic changes. If your code needs access to private fields, then please do the following, in order:
1. See if you can use a library function instead of accessing the field directly. 2. If not, see if there is already an issue on GitHub https://github.com/ARMmbed/mbedtls/issues requesting access to that field. 3. If you need a field for which there is no request for access, please raise an issue on GitHub and explain your use case. 4. If you can't wait for the field to be made accessible (either directly or via accessor functions), use MBEDTLS_PRIVATE and add a comment to your code with the issue reference.
You can use the mbedtls_2to3.py script from https://github.com/ARMmbed/mbedtls/pull/4800 https://github.com/ARMmbed/mbedtls/pull/4800 to locate access to private fields in a way that's nicer than poring through compiler errors.
Best regards,
Thank you for the detailed explanation. I would then avoid using the `MBEDTLS_ALLOW_PRIVATE_ACCESS` approach. Thanks and Regards, Aditya.
On 08-Nov-2021, at 11:04 PM, Gilles Peskine via mbed-tls mbed-tls@lists.trustedfirmware.org wrote:
[External: This email originated outside Espressif]
Hi Aditya,
As you've discovered, MBEDTLS_ALLOW_PRIVATE_ACCESS gives access to all private fields. We have deliberately not documented it because it's an internal implementation detail: it was intended only to allow access to all private fields from inside the Mbed TLS library code, and in invasive tests. It may change at any time without warning.
I do not recommend using it. You'll save some time now, but you'll have a harder time later when private fields change and your code might still compile, but have bugs due to semantic changes. If your code needs access to private fields, then please do the following, in order:
- See if you can use a library function instead of accessing the field
directly. 2. If not, see if there is already an issue on GitHub https://github.com/ARMmbed/mbedtls/issues requesting access to that field. 3. If you need a field for which there is no request for access, please raise an issue on GitHub and explain your use case. 4. If you can't wait for the field to be made accessible (either directly or via accessor functions), use MBEDTLS_PRIVATE and add a comment to your code with the issue reference.
You can use the mbedtls_2to3.py script from https://github.com/ARMmbed/mbedtls/pull/4800 https://github.com/ARMmbed/mbedtls/pull/4800 to locate access to private fields in a way that's nicer than poring through compiler errors.
Best regards,
-- Gilles Peskine Mbed TLS developer
On 08/11/2021 10:22, Aditya Patwardhan via mbed-tls wrote:
Hi, While working on updating mbedtls to v3.0, I saw that the internal fields in MBEDTLS have been made private. ( ref- here https://github.com/ARMmbed/mbedtls/blob/development/docs/3.0-migration-guide.md#most-structure-fields-are-now-private). It says there and I quote "As a last resort, you can access the field |foo| of a structure |bar| by writing |bar.MBEDTLS_PRIVATE(foo)|. Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.”
I just wanted to know if there is any alternative solution to this, rather than using `MBEDTLS_PRIVATE` everywhere. I know the next release of mbedtls probably plans to fix this with appropriate solution. But we wanted to push out our feature branch As early as possible. I saw in the PR https://github.com/zephyrproject-rtos/zephyr/pull/37753 in zephyr RTOS about updating to mbedtls-3.0. They have just added this line https://github.com/ceolin/zephyr/blob/5bf3128a9703561e578651218f5bcdafb96f87ed/subsys/net/lib/sockets/sockets_tls.c#L32
#if !defined(MBEDTLS_ALLOW_PRIVATE_ACCESS) #defineMBEDTLS_ALLOW_PRIVATE_ACCESS
# endif
Is this an alternative solution to using `MBEDTLS_PRIVATE` for accessing a private field. If yes, can somebody please point me to respective document as this would greatly reduce our code-changes.
I understand there is some discussion going on in mbedtls about this change, and appropriate getter-setter functions shall be provided. But we wanted to push out out feature branch for early testing. Thanks and Regards, Aditya
-- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
mbed-tls@lists.trustedfirmware.org
-
Aditya Patwardhan -
Gilles Peskine