yuzu-emu/mbedtls
1
0
Fork 0
mirror of https://github.com/yuzu-emu/mbedtls.git synced 2024-11-23 23:15:37 +01:00
Code Issues Packages Projects Releases Wiki Activity
dd91b24764
mbedtls/tests/suites/test_suite_timing.function

75 lines
1.7 KiB
Plaintext
Raw Normal View History

Add new timing test suite that runs the timing self test
2016-07-19 15:57:00 +02:00
/* BEGIN_HEADER */
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
/* This test module exercises the timing module. Since, depending on the
* underlying operating system, the timing routines are not always reliable,
* this suite only performs very basic sanity checks of the timing API.
*/
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
#include <limits.h>
Add new timing test suite that runs the timing self test
2016-07-19 15:57:00 +02:00
#include "mbedtls/timing.h"
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
Add new timing test suite that runs the timing self test
2016-07-19 15:57:00 +02:00
/* END_HEADER */
/* BEGIN_DEPENDENCIES
* depends_on:MBEDTLS_TIMING_C
* END_DEPENDENCIES
*/
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
/* BEGIN_CASE */
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
void timing_hardclock( )
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
(void) mbedtls_timing_hardclock();
/* This goto is added to avoid warnings from the generated code. */
goto exit;
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
}
/* END_CASE */
/* BEGIN_CASE */
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
void timing_get_timer( )
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
struct mbedtls_timing_hr_time time;
(void) mbedtls_timing_get_timer( &time, 1 );
(void) mbedtls_timing_get_timer( &time, 0 );
/* This goto is added to avoid warnings from the generated code. */
goto exit;
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
}
/* END_CASE */
/* BEGIN_CASE */
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
void timing_set_alarm( int seconds )
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
{
Correct code formatting in the timing test suites
2019-02-05 09:22:20 +01:00
if( seconds == 0 )
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
mbedtls_set_alarm( seconds );
TEST_ASSERT( mbedtls_timing_alarmed == 1 );
Correct code formatting in the timing test suites
2019-02-05 09:22:20 +01:00
}
else
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
mbedtls_set_alarm( seconds );
TEST_ASSERT( mbedtls_timing_alarmed == 0 ||
mbedtls_timing_alarmed == 1 );
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
}
}
/* END_CASE */
/* BEGIN_CASE */
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
void timing_delay( int fin_ms )
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
mbedtls_timing_delay_context ctx;
int result;
Correct code formatting in the timing test suites
2019-02-05 09:22:20 +01:00
if( fin_ms == 0 )
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
mbedtls_timing_set_delay( &ctx, 0, 0 );
result = mbedtls_timing_get_delay( &ctx );
TEST_ASSERT( result == -1 );
Correct code formatting in the timing test suites
2019-02-05 09:22:20 +01:00
}
else
{
Reduce the timing tests complexity
2019-01-29 10:19:49 +01:00
mbedtls_timing_set_delay( &ctx, fin_ms / 2, fin_ms );
result = mbedtls_timing_get_delay( &ctx );
TEST_ASSERT( result >= 0 && result <= 2 );
New timing unit tests New set of unit tests for the timing module, instead of just running the selftest function. The selftest function sometimes fails on a heavily loaded machine (such as a typical continuous integration system). Because of the all-in-one nature of the test and because the exact load pattern can be hard to reproduce, it is difficult to diagnose failures of CI runs with selftest. The new tests are more separated and I strove to point out potential failure modes in comments. * mbedtls_timing_hardclock: not tested. This function gives so few guarantees that there isn't much to test, and it is hard to test reliably because clock cycles don't easily relate to time in any remotely portable way. This function isn't used in the library anyway, it's only there for benchmark programs. * mbedtls_timing_get_timer: tested by setting a timer and verifying that it reaches its target, and by verifying that a timer started later than another always has a smaller elapsed time. * mbedtls_set_alarm: tested by setting an alarm, busy-waiting for it and measuring the elapsed time with a timer. * mbedtls_timing_set_delay, mbedtls_timing_get_delay: tested by setting a delay object and watching it go through its two delay values, using a timer to check that the delays are passed at the expected time. The tests pass under light to moderate load, but some of them can be defeated with sufficiently heavy load. This is unavoidable since the test process to be effectively suspended for any length of time, making us think that a timer has gone on for too long.
2017-10-10 19:56:06 +02:00
}
Unit test for mbedtls_timing_hardclock Do test mbedtls_timing_hardclock. We can't reliably test much about it, but at least test that it doesn't crash, isn't constant, and doesn't look completely random.
2017-10-11 16:13:13 +02:00
}
/* END_CASE */
Reference in New Issue Copy Permalink