-
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
Expand i386 all.sh tests to include full configuration ASan builds #1810
Expand i386 all.sh tests to include full configuration ASan builds #1810
Conversation
make test | ||
|
||
msg "build: 64-bit ILP32, make, gcc" # ~ 30s | ||
cleanup | ||
cp "$CONFIG_H" "$CONFIG_BAK" | ||
scripts/config.pl full | ||
make CC=gcc CFLAGS='-Werror -Wall -Wextra -mx32' |
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.
wouldn't we want ASan build for ILP32 as well?
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.
Installing libasan
for x32 didn't seem straight forward, and I guess isn't commonly used.
If you feel we should have it, I suggest we raise a bug to avoid holding up this PR, as we'd likely have to install it outside of the package manager to get it to work.
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 changes look good.
I just added a question I would like answered before I approve
Isn't this dependant on #1778 to be merged first? |
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 code changes look good to me, however I'm having trouble testing it.
If I try to run all.sh
in this branch, it fails as expected. So far so good. Then I created a temporary branch and merged #1778 into this one before trying again, only to run into a new error:
bignum.c: In function ‘mpi_mul_hlp’:
../include/mbedtls/bn_mul.h:46:13: error: ‘asm’ operand has impossible constraints
#define asm __asm
^
../include/mbedtls/bn_mul.h:55:5: note: in expansion of macro ‘asm’
asm( \
^
bignum.c:1142:9: note: in expansion of macro ‘MULADDC_INIT’
MULADDC_INIT
^
(This was on Ubuntu 16.04.) Does it work on your machine? Is there something I could be doing wrong?
Hi @sbutcher-arm! I can confirm that by adding By the way, independently of the current issue with #1778 I think we should always use non-zero |
In my view, Mbed TLS should reasonably build with all settings of However, the fix in #1778 just gets working again the code that's been in there for years, that worked with the right compiler, so the fix is just meant to get it working again. It's a correction to the design, not a new design, which would be needed. Therefore I think we have two options:
|
Let's avoid using assembly at -O0 for now. Users would want to use assembly for an optimized use case. However, this may limit the testing we do at -O0 as assembly isn't used there. Later, to regain that test coverage, we can consider rewriting to use fewer registers. I've raised #1831 to track the enhancement with minor priority. |
@mpg suggested over in #1778, that we can wrap the assembly with:
And if I think this is the best solution. |
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.
Code LGTM
I didn't test it manually.
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 the test needs improvement. As it stands, it would no longer catch issues with the i386 assembly.
tests/scripts/all.sh
Outdated
make CC=gcc CFLAGS='-Werror -Wall -Wextra -m32' | ||
cp "$CONFIG_H" "$CONFIG_BAK" | ||
scripts/config.pl full | ||
make CC=gcc CFLAGS='-Werror -Wall -Wextra -m32 -fsanitize=address' |
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.
This builds with -O0
, meaning we might not get full warnings, but more importantly we're not testing the assembly code. I think we want to have two builds and tests: one with -O0
and the other with -O1
(with comments explaining why we need the two).
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.
Have added an additional test as suggested.
@RonEld - Can you please review this again? |
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
The i386 test builds were only building the default configuration and had no address sanitisation. This commit expands the test configuration to the full configuration in all.sh and builds with ASan for when the test suites are executed.
Added an additional i386 test to all.sh, to allow one test with -O0 which compiles out inline assembly, and one to test with -01 which includes the inline assembly.
The i386 MPI inline assembly code was being incorrectly included when all compiler optimisation was disabled.
170aa83
to
e459f07
Compare
retest |
Description
The i386 test builds were only building the default configuration and had no address sanitisation. This pull request expands the test configuration to the full configuration in
all.sh
and generates ASan builds for test suite execution.This pull request extends test coverage sufficiently that issue #1550, where the MPI assembly code on i386 which was fundamentally broken, would have been caught.
It also fixes the inline assembly which was previously only being included in builds with no optimisation, which was the opposite of what it should have been doing.
Once reviewed, this PR needs backporting.
Status
READY
Requires Backporting
Yes
Which branch?
mbedtls-2.7
andmbedtls-2.1
Todos