Hi Gábor,
Congrats on fixing the previous issues and getting Travis to pass.
Unfortunately, the complete logs of the Jenkins part of the CI can only be accessed by Arm employees so far. We have plans to move to a fully-public CI system, but this won't happen before the second half of this year. In the meantime I'm afraid you'll have to ask a team member to get you the results.
> continuous-integration/jenkins/pr-head — This commit cannot be built
> continuous-integration/jenkins/pr-merge — This commit cannot be buil
Note: this can be ignore, these are the results of the parent jobs that spawn the other jobs.
> PR-4117-head TLS Testing — Failures: all_sh-ubuntu-16.04-test_m32_o1 all_sh-ubuntu-16.04-test_memory_buffer_allocator
> PR-4117-merge TLS Testing — Failures: ABI-API-checking all_sh-ubuntu-16.04-test_memory_buffer_allocator
Note: this is a partial list of failed components (truncated due to limits in the Github notifications API). Most of them as components of tests/scripts/all.sh - if you have access to a Linux/Unix machine with the proper dependencies, you can run them locally, for example here the first one would be tests/scripts/all.sh test_m32_o1, the second one tests/scripts/all.sh test_memory_buffer_allocator.
Regarding your question about coverage: I _think_ it should work on Windows if you exclude ssl-opt.sh and compat.sh. As your work is related to X.509, excluding those SSL-related scripts should not affect coverage of the areas of interest. I'm not sure if lcov (the programs that turns gcov's raw data to human-readable form) works on Windows, I'm sure your favourite search engine will have more information than me about this 🙂
Note however that most of the development/testing tools are made with Linux in mind, so you might have an easier time running a Linux VM to use them.
As a last resort, one of the reviewers of the PRs can measure coverage on their machine - that's something I often do for PRs adding features, especially when some form of parsing is involved. Thanks for paying attention to coverage, by the way, that's really appreciated!
Best regards,
Manuel.
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 11 February 2021 11:39
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Failing CI tests, Generating coverage report
Hello Guys!
I have a branch that has been successfully built, but 4/10 tests are failing. Unfortunately I am not even able to read a log, because if I click on the details button I am redirected to a "This site can't be reached" page.
Could you help me how to check the logs regarding the Jenkins CI builds?
This is the pull request https://github.com/ARMmbed/mbedtls/pull/4117
These are the failing tests:
continuous-integration/jenkins/pr-head — This commit cannot be built
continuous-integration/jenkins/pr-merge — This commit cannot be buil
PR-4117-head TLS Testing — Failures: all_sh-ubuntu-16.04-test_m32_o1 all_sh-ubuntu-16.04-test_memory_buffer_allocator
PR-4117-merge TLS Testing — Failures: ABI-API-checking all_sh-ubuntu-16.04-test_memory_buffer_allocator
I am also working on tests to cover the new functionality, but can not run coverage report. In the makefile of the base directory of mbedtls I have found this part:
ifndef WINDOWS
# note: for coverage testing, build with:
# make CFLAGS='--coverage -g3 -O0'
covtest:
$(MAKE) check
programs/test/selftest
tests/compat.sh
tests/ssl-opt.sh
So am I right, that coverage check is only supported ot linux platform? Do I need to use that one or are there any solutions on windows?
Thank you in advance!
BR,
Gábor
Hello Guys!
I have a branch that has been successfully built, but 4/10 tests are
failing. Unfortunately I am not even able to read a log, because if I click
on the details button I am redirected to a "This site can't be reached"
page.
Could you help me how to check the logs regarding the Jenkins CI builds?
This is the pull request https://github.com/ARMmbed/mbedtls/pull/4117
These are the failing tests:
*continuous-integration/jenkins/pr-head *— This commit cannot be built
*continuous-integration/jenkins/pr-merge *— This commit cannot be buil
*PR-4117-head TLS Testing *— Failures: all_sh-ubuntu-16.04-test_m32_o1
all_sh-ubuntu-16.04-test_memory_buffer_allocator
*PR-4117-merge TLS Testing *— Failures: ABI-API-checking
all_sh-ubuntu-16.04-test_memory_buffer_allocator
I am also working on tests to cover the new functionality, but can not run
coverage report. In the makefile of the base directory of mbedtls I have
found this part:
ifndef WINDOWS
# note: for coverage testing, build with:
# make CFLAGS='--coverage -g3 -O0'
covtest:
$(MAKE) check
programs/test/selftest
tests/compat.sh
tests/ssl-opt.sh
So am I right, that coverage check is only supported ot linux platform? Do
I need to use that one or are there any solutions on windows?
Thank you in advance!
BR,
Gábor
Hello Gilles!
Thank you for your helpful answer! Unfortunately this solution to find
memory leakage problems is not working under windows (as I read), but
fortunately I was able to locate the source and now my changes are green on
the server.
Thank you, again :)
BR,
Gábor
Gilles Peskine via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> ezt írta
(időpont: 2021. febr. 10., Sze, 12:03):
> Hi Gábor,
>
> Thank you for contributing to Mbed TLS!
>
> For the memory leaks, compile with ASan(+UBSan):
> export ASAN_OPTIONS='symbolize=1'
> # also export ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer if it's not
> found automatically
> export ASAN_FLAGS='-O2 -fsanitize=address,undefined
> -fno-sanitize-recover=all'
> make CFLAGS="$ASAN_FLAGS" LDFLAGS="$ASAN_FLAGS"
>
> The SSL test scripts depend on precise versions of OpenSSL and GnuTLS.
> Versions that are too old are missing some features and recent versions
> have removed some features. Even some versions from Linux distributions
> have removed obsolete algorithms that we're still testing. If you want
> to pass all the tests on your machine, I recommend that you install them
> from source. There's a list of the versions we use on our CI at
> https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/ .
>
> When you're debugging, it's useful to run a single test case or a small
> number of test cases with ssl-opt -f 'regexp' . The logs are in
> tests/o-cli-<number>.log and tests/o-srv-<number>.log .
>
> Hope this helps.
>
> --
> Gilles Peskine
> Mbed TLS developer
>
> On 10/02/2021 10:17, Gábor Tóth via mbed-tls wrote:
> > Hello Guys!
> >
> > I am working on an update of MBEDTLS that will support AuthorityKeyId
> > and SubjetKeyId V3 extensions of X509. I have created a pull request,
> > but I have not been able to solve the issues on Travis:
> > https://github.com/ARMmbed/mbedtls/pull/4117
> >
> > As I see the problems are: memory leakage and the failure of two tests
> > suites.
> > I tried to run these suites and a memory leakage check on my host
> > machine, but the .sh scripts are just flashing once and disappearing
> > in a few seconds after catching some kind of exception.
> >
> > I have Python2, Perl, Mingw64 (with gcc) installed and added to the
> > Path. These commands are working:
> > - make CC=gcc
> > - make tests
> > All the 87 tests pass.
> >
> > Tried running ssl-opt.sh without arguments and with "-m", but it exits
> > after a few lines.
> >
> > Do you have any idea what I am missing? It would make the work much
> > easier if I could run the testsuites reproducing the error and if I
> > could find the memory leaks.
> >
> > Thank you in advance!
> >
> > BR,
> > Gábor
> >
>
>
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
Hi Gábor,
Thank you for contributing to Mbed TLS!
For the memory leaks, compile with ASan(+UBSan):
export ASAN_OPTIONS='symbolize=1'
# also export ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer if it's not
found automatically
export ASAN_FLAGS='-O2 -fsanitize=address,undefined
-fno-sanitize-recover=all'
make CFLAGS="$ASAN_FLAGS" LDFLAGS="$ASAN_FLAGS"
The SSL test scripts depend on precise versions of OpenSSL and GnuTLS.
Versions that are too old are missing some features and recent versions
have removed some features. Even some versions from Linux distributions
have removed obsolete algorithms that we're still testing. If you want
to pass all the tests on your machine, I recommend that you install them
from source. There's a list of the versions we use on our CI at
https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/ .
When you're debugging, it's useful to run a single test case or a small
number of test cases with ssl-opt -f 'regexp' . The logs are in
tests/o-cli-<number>.log and tests/o-srv-<number>.log .
Hope this helps.
--
Gilles Peskine
Mbed TLS developer
On 10/02/2021 10:17, Gábor Tóth via mbed-tls wrote:
> Hello Guys!
>
> I am working on an update of MBEDTLS that will support AuthorityKeyId
> and SubjetKeyId V3 extensions of X509. I have created a pull request,
> but I have not been able to solve the issues on Travis:
> https://github.com/ARMmbed/mbedtls/pull/4117
>
> As I see the problems are: memory leakage and the failure of two tests
> suites.
> I tried to run these suites and a memory leakage check on my host
> machine, but the .sh scripts are just flashing once and disappearing
> in a few seconds after catching some kind of exception.
>
> I have Python2, Perl, Mingw64 (with gcc) installed and added to the
> Path. These commands are working:
> - make CC=gcc
> - make tests
> All the 87 tests pass.
>
> Tried running ssl-opt.sh without arguments and with "-m", but it exits
> after a few lines.
>
> Do you have any idea what I am missing? It would make the work much
> easier if I could run the testsuites reproducing the error and if I
> could find the memory leaks.
>
> Thank you in advance!
>
> BR,
> Gábor
>
Hello Guys!
I am working on an update of MBEDTLS that will support AuthorityKeyId and
SubjetKeyId V3 extensions of X509. I have created a pull request, but I
have not been able to solve the issues on Travis:
https://github.com/ARMmbed/mbedtls/pull/4117
As I see the problems are: memory leakage and the failure of two tests
suites.
I tried to run these suites and a memory leakage check on my host machine,
but the .sh scripts are just flashing once and disappearing in a few
seconds after catching some kind of exception.
I have Python2, Perl, Mingw64 (with gcc) installed and added to the Path.
These commands are working:
- make CC=gcc
- make tests
All the 87 tests pass.
Tried running ssl-opt.sh without arguments and with "-m", but it exits
after a few lines.
Do you have any idea what I am missing? It would make the work much easier
if I could run the testsuites reproducing the error and if I could find the
memory leaks.
Thank you in advance!
BR,
Gábor
Hi, im using mbedtls 2.7.17 in my project on stm32f417 (168Mhz) with config similar to config-mini-tls1_1.h for server HTTPS support (Keil).
mbedtls_rsa_private is executed ~19seconds on key_exchange phase on browser connection. I’m use default embedded test RSA ca, cert and pkey. Compilation with speed optimization and without not signaficantly reduces this time. Is it normal time of caclulation or something wrong with my platform? I’m expected about 1-2s, not 19..How can i reduce execution time as an expected?
Thanks.
#ifndef MBEDTLS_CONFIG_H
#define MBEDTLS_CONFIG_H
/* System support */
#define MBEDTLS_HAVE_ASM
#define MBEDTLS_HAVE_TIME
/* mbed TLS feature support */
#define MBEDTLS_CIPHER_MODE_CBC
#define MBEDTLS_PKCS1_V15
#define MBEDTLS_KEY_EXCHANGE_RSA_ENABLED
#define MBEDTLS_SSL_PROTO_TLS1_1
/* mbed TLS modules */
#define MBEDTLS_AES_C
#define MBEDTLS_ASN1_PARSE_C
#define MBEDTLS_ASN1_WRITE_C
#define MBEDTLS_BIGNUM_C
#define MBEDTLS_CIPHER_C
#define MBEDTLS_CTR_DRBG_C
#define MBEDTLS_DES_C
#define MBEDTLS_ENTROPY_C
#define MBEDTLS_MD_C
#define MBEDTLS_MD5_C
//#define MBEDTLS_NET_C
#define MBEDTLS_OID_C
#define MBEDTLS_PK_C
#define MBEDTLS_PK_PARSE_C
#define MBEDTLS_RSA_C
#define MBEDTLS_SHA1_C
#define MBEDTLS_SHA256_C
//#define MBEDTLS_SSL_CLI_C
#define MBEDTLS_SSL_SRV_C
#define MBEDTLS_SSL_TLS_C
#define MBEDTLS_X509_CRT_PARSE_C
#define MBEDTLS_X509_USE_C
/* For test certificates */
#define MBEDTLS_BASE64_C
#define MBEDTLS_CERTS_C
#define MBEDTLS_PEM_PARSE_C
/* For testing with compat.sh */
//#define MBEDTLS_FS_IO
#define MBEDTLS_NO_PLATFORM_ENTROPY
#include "mbedtls/check_config.h"
#endif /* MBEDTLS_CONFIG_H */
--
Dmitry X
Hello,
RSA key objects include a mutex. `mbedtls_rsa_private` locks the mutex
because it caches some auxiliary values used for blinding in the key
object. (`mbedtls_rsa_public` also locks the mutex but it seems
pointless.) This allows applications to create a key (this must be done
in a single-threaded way), then use that key concurrently.
This feature has a number of downsides. From a high-level architectural
perspective, the RSA module is a low-level part of the code dedicated to
peforming calculations; managing concurrency is outside its scope. The
presence of the mutex complicates the lifecycle of RSA contexts, leading
to unmet expectations (https://github.com/ARMmbed/mbedtls/issues/2621)
and bugs on certain platforms
(https://github.com/ARMmbed/mbedtls/pull/4104). ECC contexts do not have
a mutex, even though they would need one, so a multithreaded application
that works with RSA keys can't easily be changed to ECC keys.
As a consequence, I propose to remove mutexes from RSA keys in Mbed TLS
3.0. Applications that currently rely on the mutex should either migrate
to the PSA API or wrap an RSA object (or a pk object, which would allow
algorithm agility) in a mutex.
This proposal is also recorded with more details at
https://github.com/ARMmbed/mbedtls/issues/4124 .
--
Gilles Peskine
Mbed TLS developer
Hi Frank,
Support for HSM keys in Mbed TLS is a work in progress. The way it will
work eventually is by plugging an HSM driver under the PSA crypto API,
which supports both transparent and opaque keys.
The TLS code can already use the PSA crypto API for some things,
including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call
mbedtls_pk_setup_opaque() to create a PK object for the key, and declare
the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual.
To create the key, you will need to write a PKCS#11 secure element
driver. ("Secure element" = "HSM" for this purpose.) I think it would
make sense to have one in Mbed TLS, but I don't know when we might get
around to writing one.
There are two secure element driver interfaces in Mbed TLS right now:
MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and
MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still
experimental: we can't guarantee API stability at this stage.
MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is
currently frozen and may be abandonned, so I don't recommend investing
any effort in it at the moment, but if you need something fast (e.g. for
a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS
is the way of the future, but it's an active work in progress.
If you're creating the key from your application, just call
psa_generate_key. If the key was provisioned externally, it's
unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can
register a key that's already present in the secure element with
mbedtls_psa_register_se_key(). The corresponding facility in the
MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point,
but this is not implemented yet. (There's a prototype at
https://github.com/ARMmbed/mbedtls/pull/3822 but nobody is working on
it. The specification is in docs/proposed/psa-driver-interface.md.)
There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at
https://github.com/ARMmbed/mbed-os-example-atecc608a . We don't have
example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation,
or an easy-to-use build system — those are still a few months in the future.
If you write a driver in the next few months, I recommend that you stay
in touch with the Mbed TLS development team and follow the development
branch of Mbed TLS closely, since it's a very active area of development
at the moment.
--
Gilles Peskine
Mbed TLS developer
On 06/02/2021 16:59, Frank Bergmann via mbed-tls wrote:
> Hi,
>
> I want to use PKCS#11 with mbed TLS...
>
> - cross platform: Windows, mobile device (e.g. Android), *nix
> - on *client* side
> - to create keys (for certs) and store private keys in an HSM (could also be e.g. softhsm as fallback)
>
> How to "integrate" PKCS#11 with mbed TLS and achieve those requirements?
>
>
> cheers,
> Frank
>
Dear Farhad,
Sure, the thing you need to do is to call mbedtls_ssl_conf_authmode( conf, MBEDTLS_SSL_VERIFY_REQUIRED ) where conf is the ssl_config of the server. For more details, see that function's documentation (in ssl.h). For an example, see the command-line option auth_mode in programs/ssl/ssl_server2.c.
Hope this helps!
Best regards,
Manuel
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of saghili via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 05 February 2021 17:34
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] DTLS Mutual authentication
Dear,
I would like to have mutual authentication using dtls_client.c and
dtls_server.c examples.
In the current version of the example, the client does not send his own
certificate and the server does not verify the certificate of the
client.
Could you please provide me the changes that I need to make in both
dtls_client.c and dtls_server.c examples?
Best regards,
Farhad
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi,
I want to use PKCS#11 with mbed TLS...
- cross platform: Windows, mobile device (e.g. Android), *nix
- on *client* side
- to create keys (for certs) and store private keys in an HSM (could also be e.g. softhsm as fallback)
How to "integrate" PKCS#11 with mbed TLS and achieve those requirements?
cheers,
Frank