Add unit tests for mask_of_range(), enc_char() and dec_value().
When constant-flow testing is enabled, verify that these functions are
constant-flow.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
I had originally thought to support directories with
mbedtls_x509_crt_parse_path but it would have complicated the code more than
I cared for. Remove a remnant of the original project in the documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
To test c <= high, instead of testing the sign of (high + 1) - c, negate the
sign of high - c (as we're doing for c - low). This is a little easier to
read and shaves 2 instructions off the arm thumb build with
arm-none-eabi-gcc 7.3.1.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
n was used for two different purposes. Give it a different name the second
time. This does not seem to change the generated code when compiling with
optimization for size or performance.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of doing constant-flow table lookup, which requires 64 memory loads
for each lookup into a 64-entry table, do a range-based calculation, which
requires more CPU instructions per range but there are only 5 ranges.
I expect a significant performance gain (although smaller than for decoding
since the encoding table is half the size), but I haven't measured. Code
size is slightly smaller.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Document what each local variable does when it isn't obvious from the name.
Don't reuse a variable for different purposes.
This commit has very little impact on the generated code (same code size on
a sample Thumb build), although it does fix a theoretical bug that 2^32
spaces inside a line would be ignored instead of treated as an error.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of doing constant-flow table lookup, which requires 128 memory loads
for each lookup into a 128-entry table, do a range-based calculation, which
requires more CPU instructions per range but there are only 5 ranges.
Experimentally, this is ~12x faster on my PC (based on
programs/x509/load_roots). The code is slightly smaller, too.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Base64 decoding uses equality comparison tests for characters that don't
leak information about the content of the data other than its length, such
as whitespace. Do this with '=' as well, since it only reveals information
about the length. This way the table lookup can focus on character validity
and decoding value.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a line in the README explaining that CMake will generate
the files it needs automatically on non-Windows systems
when not cross-compiling.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
If on windows, turn off GEN_FILES as it does not currently
work (for reasons unknown).
Note: The WIN32 variable is "True on windows systems,
including win64", as one would expect.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The Makefiles already assume that filenames don't contain
special characters anyway, so we don't need to check this
in generate_psa_tests.py.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Change one occurrence of ${PYTHON} to ${MBEDTLS_PYTHON_EXECUTABLE}
and add implied ${MBEDTLS_PYTHON_EXECUTABLE} to the start of a
different command.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Explain that the output filename is derived from the -d
argument, so that it's obvious why the CMakefile code
does what it does.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When DEV_MODE=OFF, link_to_source() was being called with
a full path in the build directory, rather than just a base
name starting at "suites/" as was intended. Fix this by
generating a list of base names and using that for
link_to_source(), then deriving full paths afterwards.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Add usage information to the ARGV-incorrect-length error
message in generate_query_config.pl. A plain usage message
looks a bit incongruous when raised as an error, but the
error message alone is unhelpful.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Remove a hardcoded list of tests that use generated
".data" files, and instead derive this list from the existing
list of test files (created using generate_psa_tests.py).
This reduces the maintenance burden as only the list
in generate_psa_tests.py needs to be updated.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Add a new function that takes a string and removes the
portion following the last '.' character, usually a file
extension. This would transform:
* "a.b.c" into "a.b"
* "name." into "name"
* ".name" into ""
* "no_dot" into "no_dot" (i.e. no change)
CMake's existing file-extension-removal command removes
the largest possible extension which would make "a.b.c"
into "a", which is incorrect for handling tests that have
'.'s within their names.
The desired behaviour was added in CMake 3.14, but we
support CMake >= 3.5.1 (for 3.0) and >= 2.8.12.2 (for 2.x)
at the time of writing.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Use the generate_psa_tests.py script to generate the list
of test data files used as output files by cmake.
Do this by introducing a new option --list-for-cmake
that prints a semicolon-separated list of the data files
with no terminating newline (since this is how a cmake list
is represented).
Replace the hard-coded output file list with a variable
generated by the script using this option.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Unrelated to other commits in this PR, except when running manual tests
I kept noticing these files where left over.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
When the option is On, CMake will have rules to generate the generated
files using scripts etc. When the option is Off, CMake will assume the
files are available from the source tree; in that mode, it won't require
any extra tools (Perl for example) compared to when we committed the
files to git.
The intention is that users will never need to adjust this option:
- in the development branch (and features branches etc.) the option is
always On (development mode);
- in released tarballs, which include the generated files, we'll switch
the option to Off (release mode) in the same commit that re-adds the
generated files.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Due to the directory test/suites being linked, the files generated there
where actually written to the source tree, not just the binary tree.
We no longer need this directory to be linked, that was a remnant of the
time where the .data files were read while running the tests; nowadays
they're processed when generating the test .c file.
Just create the directory, as the generating script quite reasonably
assumes that the output directory passed on the command line exists.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Note: the test suites are actually generated in the source tree, due to
the use of
link_to_source(suites)
This will be fixed in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- avoid very long lines
- match order of command arguments and dependencies
- group compiler flags together
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This one's a bit funny too as the generated file is not a source to the
executable (ie, it's not passed as an argument to the compiler), so
CMake's dependency resolution didn't work even though the file is in the
same directory.
For some reason, the following didn't work either:
add_dependencies(psa_constant_names
${CMAKE_CURRENT_BINARY_DIR}/psa_constant_names_generated.c)
So, apply the same strategy as for cross-directory use of a generated
file by creating a target and using it as a dependency.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
query_config was added twice, and while at it let's declare all the
sources in one place
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
