-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Conversation
@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? |
Sure, I will add this to my to do list and hopefully get to it within a few
days.
|
This now applies on the |
Unfortunately on the CI
Additionally
|
Have you tried running the test suites with |
Fascinating. I'll try all-in-docker and report back. |
Weird, Can you copy out a little more of the context for the first failure please? (the one with the I can replicate the failure for |
It is weird. Some more context on the error:
And it goes on like that with many more source files. |
@daxtens I just learned that |
oh that's good to know. I will give that a go.
|
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]>
Signed-off-by: Andrzej Kurek <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
Signed-off-by: Andrzej Kurek <[email protected]>
Rebased to have a passing CI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ping @d3zd3z to review |
Backport (#5563) is approved, so this PR and 5563 are ready to be merged |
CI failures ( Internal CI all passes |
@@ -157,6 +158,26 @@ int mbedtls_timing_get_delay( void *data ) | |||
|
|||
return( 0 ); | |||
} | |||
#else |
There was a problem hiding this comment.
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))
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Description
This attempts to bring together #3444 and (an earlier version of) #3449: it adds tests to catch bad uses of
time.h
whenMBEDTLS_HAVE_TIME
is not defined.The idea is to add an additional, overriding include directory that
#error
s out iftime.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
Steps to test or reproduce
Run the tests, specifically
build_baremetal
andbuild_crypto_baremetal
.