Code review request for FIPS 140-2 administration and POST changes

[Hai-May Chao]

Darren J Moffat wrote:
> Hai-May Chao wrote:
>> All the new fips_<cipher>.h files are introduced because of the
>> code sharing between userland and kernel modules.
>>
>> For example, some of the definitions and structures were moved
>> from sha1_mod.c to fips_sha1.h so that these definitions can be
>> included in the common code, fips_sha1_util.c, and shared by
>> both kernel module (sha1_mod.c) and userland softtoken
>> (softFipsPostUtil.c). The same design applies to other FIPS
>> required ciphers. This code sharing save 80% of the code
>> duplication.
>
> I don't see what that means we need to have fips_sha1.h why can't 
> these definitions - which mostly have nothing to do with FIPS 140 - 
> just go into the already existing header files that are shared between 
> user and kernel, eg <sys/sha1.h>, <sys/sha2.h>.
>
> The code sharing I'm very happy with it is the layout and the 
> apparently "special" fips header files I'm confused by.
>


I see your valuable points here. However,  I have my design thoughts as 
follows.

1. If changes are made to sha1.h, sha2.h and other global headers, all 
the applications
   that include the changed header files will have to recompile and 
rebuild.
   This impact is too big.

2. Most of the definitions and external function declarations in the new 
header files
   are still specific to FIPS POST. The existing header files and 
corresponding
   applicaitons do not need to know all these new changes.

3. To add the new fips_sha1.h, fips_sha2.h, and other header files can 
avoid the
   global impact. Besides,  all the FIPS related code will be more 
modular  and
   isolated from the existing files.

Thanks,
Hai-May