Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Fix builds with MBEDTLS_HAVE_TIME disabled and test #3624

Merged
merged 17 commits into from
Mar 15, 2022

Conversation

daxtens
Copy link
Contributor

@daxtens daxtens commented Aug 31, 2020

Description

This attempts to bring together #3444 and (an earlier version of) #3449: it adds tests to catch bad uses of time.h when MBEDTLS_HAVE_TIME is not defined.

The idea is to add an additional, overriding include directory that #errors out if time.h is included.

I wanted to get some feedback before I do the changelog and backports.

Status

IN DEVELOPMENT

Requires Backporting

Yes

Which branch? - I'm not sure and would appreciate guidance.

Migrations

NO

Additional comments

Ping @naynajain and @raoulstrackx.

Todos

  • Tests
  • Documentation
  • Changelog updated
  • Backported

Steps to test or reproduce

Run the tests, specifically build_baremetal and build_crypto_baremetal.

@daverodgman daverodgman added the needs-review Every commit must be reviewed by at least two team members, label Sep 3, 2020
@daverodgman daverodgman added Community needs-reviewer This PR needs someone to pick it up for review labels Oct 2, 2020
@mstarzyk-mobica mstarzyk-mobica removed the needs-reviewer This PR needs someone to pick it up for review label Apr 1, 2021
@yanesca yanesca added the needs-reviewer This PR needs someone to pick it up for review label Aug 9, 2021
@yanesca
Copy link
Contributor

yanesca commented Aug 9, 2021

@daxtens I am sorry we somehow lost track of this PR. We would be happy to review it now if you still would like to contribute. Would you like to resolve the conflicts?

@daxtens
Copy link
Contributor Author

daxtens commented Aug 10, 2021 via email

@daxtens
Copy link
Contributor Author

daxtens commented Aug 19, 2021

This now applies on the development branch and the build_baremetal and build_crypto_baremetal test suites pass on my Linux x86_64 laptop.

@yanesca
Copy link
Contributor

yanesca commented Aug 19, 2021

Unfortunately on the CI ./tests/scripts/all.sh build_baremetal and ./tests/scripts/all.sh build_crypto_baremetal are failing:

/var/lib/build/tests/include/baremetal-override/time.h:18:2: error: #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
#error "time.h included in a configuration without MBEDTLS_HAVE_TIME"

Additionally ./tests/scripts/all.sh test_malloc_0_null is failing as well:

In file included from ../../include/mbedtls/build_info.h:59:0,
from ../../include/mbedtls/platform_time.h:25,
from common.h:8,
from common.c:1:
/var/lib/build/tests/configs/config-wrapper-malloc-0-null.h:24:21: error: redefinition of 'custom_calloc'
static inline void *custom_calloc( size_t nmemb, size_t size )

@yanesca
Copy link
Contributor

yanesca commented Aug 19, 2021

Have you tried running the test suites with ./tests/scripts/all-in-docker.sh? (It supposed to replicate the exact environment on the CI.)

@daxtens
Copy link
Contributor Author

daxtens commented Aug 19, 2021

Fascinating. I'll try all-in-docker and report back.

@daxtens
Copy link
Contributor Author

daxtens commented Aug 20, 2021

Weird, ./tests/scripts/all-in-docker.sh build_crypto_baremetal and build_baremetal pass for me.

Can you copy out a little more of the context for the first failure please? (the one with the #error from time.h)

I can replicate the failure for test_malloc_0_null. I'll fix that up.

@yanesca
Copy link
Contributor

yanesca commented Aug 20, 2021

It is weird. Some more context on the error:

  CC    psa_crypto_aead.c
  CC    psa_crypto_driver_wrappers.c
  CC    psa_crypto_mac.c
  CC    oid.c
  CC    psa_crypto_se.c
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:132:0,
                 from /usr/include/stdlib.h:314,
                 from ../include/mbedtls/platform.h:64,
                 from aes.c:33:
/var/lib/build/tests/include/baremetal-override/time.h:18:2: error: #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
 #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
  ^
In file included from /usr/include/x86_64-linux-gnu/sys/select.h:43:0,
                 from /usr/include/x86_64-linux-gnu/sys/types.h:219,
                 from /usr/include/stdlib.h:314,
                 from ../include/mbedtls/platform.h:64,
                 from aes.c:33:
/var/lib/build/tests/include/baremetal-override/time.h:18:2: error: #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
 #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
  ^
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:132:0,
                 from /usr/include/stdlib.h:314,
                 from ../include/mbedtls/platform.h:64,
                 from aria.c:36:
/var/lib/build/tests/include/baremetal-override/time.h:18:2: error: #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
 #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
  ^
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:132:0,
                 from /usr/include/stdlib.h:314,
                 from ../include/mbedtls/threading.h:28,
                 from ecp.c:76:
/var/lib/build/tests/include/baremetal-override/time.h:18:2: error: #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
 #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
  ^
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:132:0,
                 from /usr/include/stdlib.h:314,
                 from ../include/mbedtls/platform.h:64,
                 from ssl_cache.c:29:
/var/lib/build/tests/include/baremetal-override/time.h:18:2: error: #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
 #error "time.h included in a configuration without MBEDTLS_HAVE_TIME"
  ^

And it goes on like that with many more source files.

@gilles-peskine-arm gilles-peskine-arm added needs-ci Needs to pass CI tests and removed needs-review Every commit must be reviewed by at least two team members, needs-reviewer This PR needs someone to pick it up for review labels Aug 31, 2021
@yanesca
Copy link
Contributor

yanesca commented Sep 2, 2021

@daxtens I just learned that ./tests/scripts/all-in-docker.sh doesn't work as expected: it compiles the library on the host and runs the tests in the docker. Can you try manually building and running the test inside the docker image?

@daxtens
Copy link
Contributor Author

daxtens commented Sep 2, 2021 via email

davidhorstmann-arm and others added 11 commits March 4, 2022 05:07
Remove direct inclusion of mbedtls_config.h and replace with
build_info.h, as is the convention in Mbed TLS 3.0.

Signed-off-by: David Horstmann <[email protected]>
MBEDTLS_HAVE_TIME_ALT implies MBEDTLS_HAVE_TIME, so an extra
check for MBEDTLS_HAVE_TIME is not needed.

Signed-off-by: David Horstmann <[email protected]>
Change the new baremetal all.sh tests to use $PWD rather than
calling pwd again directly.

Signed-off-by: David Horstmann <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
@AndrzejKurek
Copy link
Contributor

Rebased to have a passing CI.

Copy link
Contributor

@tom-cosgrove-arm tom-cosgrove-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AndrzejKurek AndrzejKurek requested a review from d3zd3z March 4, 2022 18:18
@tom-cosgrove-arm
Copy link
Contributor

ping @d3zd3z to review

@tom-cosgrove-arm tom-cosgrove-arm added approved Design and code approved - may be waiting for CI or backports and removed needs-backports Backports are missing or are pending review and approval. labels Mar 9, 2022
@tom-cosgrove-arm
Copy link
Contributor

Backport (#5563) is approved, so this PR and 5563 are ready to be merged

@tom-cosgrove-arm
Copy link
Contributor

tom-cosgrove-arm commented Mar 15, 2022

CI failures (ci.trustedfirmware.org): 4 x Scripts not permitted to use new java.util.NoSuchElementException java.lang.String + 1 x No such property: pullRequest for class: groovy.lang.Binding

Internal CI all passes

@daverodgman daverodgman merged commit 2cecd8a into Mbed-TLS:development Mar 15, 2022
@@ -157,6 +158,26 @@ int mbedtls_timing_get_delay( void *data )

return( 0 );
}
#else
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

09e803c introduces a dummy implementation of timer functions. Now, when defined(MBEDTLS_TIMING_C) && !defined(MBEDTLS_TIMING_ALT) && !defined(MBEDTLS_HAVE_TIME) (did I get this condition right?), the functions mbedtls_timing_get_timer, mbedtls_timing_set_delay and mbedtls_timing_get_delay exist but they pretend that no time ever elapses.

What is the point of this dummy implementation? Why not make MBEDTLS_TIMING_C require MBEDTLS_HAVE_TIME || MBEDTLS_TIMING_ALT, since this seems to be necessary to implement the timing functions?

The dummy implementation breaks #5582 and I'm trying to figure out how to fix this. Before #3624, in #5582, I made a configuration config-ccm-psk-dtls1_2.h with MBEDTLS_TIMING_C enabled but not MBEDTLS_HAVE_TIME, and I got ssl-opt.sh to pass. Since #3624, the test cases in ssl-opt.sh that use udp_proxy … pack=50 are failing, because the pack option of the proxy does not work with the dummy implementation of mbedtls_timing_get_timer. The pack options causes the proxy to accumulate packets until a certain amount of time has elapsed, but with the dummy implementation, this never happens, so the proxy never forwards any packet.

Currently, in udp_proxy.c, opt.pack is only accepted if defined(MBEDTLS_TIMING_C). Should this change to … && (defined(MBEDTLS_HAVE_TIME) || defined(MBEDTLS_TIMING_ALT))?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I recall the discussion correctly (and looking at mbedtls_config.h), MBEDTLS_TIMING_C itself provides only the interface that is to be filled by either MBEDTLS_HAVE_TIME, or MBEDTLS_TIMING_ALT.
I would assume that if someone wants to have the interface, but does not wish to provide any working stub - this is the way to go. I don't know why would this be desirable, but that's the way it works now.
It might make sense to go a step further, add dependencies for MBEDTLS_TIMING_C as you mentioned and get rid of the dummy code, but this was out of scope for this PR.
For now, yes, to have a working implementation, (defined(MBEDTLS_HAVE_TIME) || defined(MBEDTLS_TIMING_ALT)) is the way to go.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to think those three functions should depend on defined(MBEDTLS_HAVE_TIME) || defined(MBEDTLS_TIMING_ALT) and not be declared otherwise. (Just like for example, mbedtls_ssl_cache_set_timeout() is only declared if HAVE_TIME is defined.) Not being defined seems better than having a dummy implementation that's not suitable for any use: when something doesn't work, it's better for the error to be at compile-time than at runtime.

Now, whether that's a change we can make now without breaking backwards compat as another question. If the difference only happens in builds that were anyway not working in the previous release, then we're good, otherwise we're stuck.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we take the dummy implementation out there will be several compile failures - it's on my list to check, hopefully later today

Copy link
Contributor

@AndrzejKurek AndrzejKurek Apr 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we take the dummy implementation out there will be several compile failures - it's on my list to check, hopefully later today

I have done that already - with the default config minus HAVE_TIME and HAVE_TIME_DATE, but with TIMING_C, test_suite_ssl and test_suite_timing will not compile, also dtls_server, dtls_client and ssl_client2 from programs will fail to compile.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you take mbedtls-3.1 and build with default config minus MBEDTLS_HAVE_TIME and MBEDTLS_HAVE_TIME_DATE on a platform that actually has a working time.h, make lib test works but make programs doesn't. The build of the library breaks in this same configuration if time.h is not available — which was the purpose of this PR.

Is it acceptable for us to break custom configurations that accidentally work because the developer didn't include MBEDTLS_HAVE_TIME in the configuration, but could have? If we do, at the very least, this should be prominently mentioned in the changelog entry.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you take mbedtls-3.1 and build with default config minus MBEDTLS_HAVE_TIME and MBEDTLS_HAVE_TIME_DATE on a platform that actually has a working time.h, make lib test works but make programs doesn't

So you are removing any implementation (by saying "don't have time or date" and not providing _ALT) but leaving MBEDTLS_TIMING_C set, so this seems reasonable if we say that for MBEDTLS_TIMING_C you need either "have time/date" or _ALT

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build of the library breaks in this same configuration if time.h is not available

Err, I find that the library doesn't try to include a time.h file if I take development and just disable MBEDTLS_HAVE_TIME and MBEDTLS_HAVE_TIME_DATE - let me investigate further

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tom-cosgrove-arm Before this PR (e.g. in 3.1), platform.h included time.h even when MBEDTLS_HAVE_TIME was disabled.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gilles-peskine-arm So I have double-checked: if I take a working Ubuntu build system, rename time.h out of the way, take Mbed TLS development and disable only MBEDTLS_HAVE_TIME and MBEDTLS_HAVE_TIME_DATE, the whole thing builds (as you say, that was the purpose of the PR). i.e. I can't reproduce your failure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Design and code approved - may be waiting for CI or backports bug component-platform Portability layer and build scripts enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.