Dan Anderson wrote:
> First, thanks for all the function block comments--it really helps.
>
> DEA-1 & DEA-2: see a previous review.
>
> DEA-3: /usr/src/uts/common/sys/crypto/ioctladmin.h
> Typo: s/occured/occurred/
> 140 FIPS140_MODE_SHUTDOWN, /* Failure has occured, shutdown framework */
>
> DEA-4: /usr/src/uts/common/crypto/core/kcf.
> Typo: s/disable/disabled/
> 147 * If FIPS 140 has failed its tests. The providers must be disable from the
>
> DEA-5: /usr/src/uts/common/crypto/core/kcf.c
> As a sanity check on FIPS140_MODULES_MAX, it should be used in the static
> array declaration so the compiler can catch incorrect values for this
> constant:
> That is change line 78 to:
> static char *fips140_module_list[FIPS140_MODULES_MAX] ...
>
> 78 static char *fips140_module_list[] = {
> 79 "aes", "des", "ecc", "sha1", "sha2", "rsa", "swrand"
> 80 };
>
The above are accepted.. thanks..
> DEA-6: /usr/src/uts/common/crypto/core/kcf.c
> I have a question for function kcf_fips140_validate().
> It starts threads at the beginning and waits for threads at the end.
> What happens if, say, there's an error, say, on the third loop with "ecc".
> The code does a goto error, without waiting for the first 2 threads (for aes
> and des) to complete. Can this cause a problem? (as you wait for the threads
> to complete (join) with in the non-error case).
That is intentional. If there is an error at any point during the
validation process I can abort and shutdown the providers. The modules
finishing their POST tests is ok since they will be soon disabled.. The
join is to make sure all the return values from the POST operations were
successful..
thanks
Tony
