From f5b567afab73f5a41a4704ca841f25d9d7a463d4 Mon Sep 17 00:00:00 2001 From: kh0705 Date: Tue, 18 Aug 2020 14:38:38 +0900 Subject: [PATCH] Keymaster: update the verifyAuthorization call time and delta time in VerificationToken VTS The keymaster function affects the performance of secure os. When considering the swtiching time of the normal world < - > Secure world and the processing delay of the SecureOS by the scheduling policy of the normal world, it is necessary to increase the time. Even though Secure world is no problem, Sometimes there is a possibility of that the test will fail because it is a limited resource normal world. On average, it is performed in a very fast time, but sometimes it takes a lot of time. After many tests, the safe time was measured. Bug: 162115135 Change-Id: I55862204ef71f69bc88c79fe2259f7cb8365699a Signed-off-by: kh0705 --- .../4.0/vts/functional/VerificationTokenTest.cpp | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/keymaster/4.0/vts/functional/VerificationTokenTest.cpp b/keymaster/4.0/vts/functional/VerificationTokenTest.cpp index bab1439584..4f0a7a3a14 100644 --- a/keymaster/4.0/vts/functional/VerificationTokenTest.cpp +++ b/keymaster/4.0/vts/functional/VerificationTokenTest.cpp @@ -111,19 +111,19 @@ TEST_P(VerificationTokenTest, TestCreation) { EXPECT_GE(host_time_delta, time_to_sleep) << "We slept for " << time_to_sleep << " ms, the clock must have advanced by that much"; - EXPECT_LE(host_time_delta, time_to_sleep + 20) + EXPECT_LE(host_time_delta, time_to_sleep + 100) << "The verifyAuthorization call took " << (host_time_delta - time_to_sleep) << " ms? That's awful!"; auto km_time_delta = result2.token.timestamp - result1.token.timestamp; // If not too much else is going on on the system, the time delta should be quite close. Allow - // 2 ms of slop just to avoid test flakiness. + // 20 ms of slop just to avoid test flakiness. // // TODO(swillden): see if we can output values so they can be gathered across many runs and // report if times aren't nearly always <1ms apart. - EXPECT_LE(host_time_delta, km_time_delta + 2); - EXPECT_LE(km_time_delta, host_time_delta + 2); + EXPECT_LE(host_time_delta, km_time_delta + 20); + EXPECT_LE(km_time_delta, host_time_delta + 20); ASSERT_EQ(result1.token.mac.size(), result2.token.mac.size()); ASSERT_NE(0, memcmp(result1.token.mac.data(), result2.token.mac.data(), result1.token.mac.size())); @@ -172,14 +172,14 @@ TEST_P(VerificationTokenTest, MacChangesOnChangingTimestamp) { EXPECT_GE(host_time_delta, time_to_sleep) << "We slept for " << time_to_sleep << " ms, the clock must have advanced by that much"; - EXPECT_LE(host_time_delta, time_to_sleep + 20) + EXPECT_LE(host_time_delta, time_to_sleep + 100) << "The verifyAuthorization call took " << (host_time_delta - time_to_sleep) << " ms? That's awful!"; auto km_time_delta = result2.token.timestamp - result1.token.timestamp; - EXPECT_LE(host_time_delta, km_time_delta + 2); - EXPECT_LE(km_time_delta, host_time_delta + 2); + EXPECT_LE(host_time_delta, km_time_delta + 20); + EXPECT_LE(km_time_delta, host_time_delta + 20); ASSERT_EQ(result1.token.mac.size(), result2.token.mac.size()); ASSERT_NE(0, memcmp(result1.token.mac.data(), result2.token.mac.data(), result1.token.mac.size()));