On Fri, 2021-04-09 at 14:56 -0400, Simo Sorce wrote: > Hi Jason, > I can't speak for Hangbin, we do not work for the same company and I > was not aware of his efforts until this patch landed. Turns out I and Hangbin do work for the same company after all. Left hand is meeting right hand internally now. :-D The comments still stand of course. Simo. > For my part we were already looking at big_key, wireguard and other > areas internally, but were not thinking of sending upstream patches > like these w/o first a good assessment with our teams and lab that they > were proper and sufficient. > > > So > > I think either you should send an exhaustive patch series that forbids > > all use of non-FIPS crypto anywhere in the kernel (another example: > > net/core/secure_seq.c) in addition to all tunneling modules that don't > > use FIPS-certified crypto, or figure out how to disable the lib/crypto > > primitives that you want to be disabled in "fips mode". With a > > coherent patchset for either of these, we can then evaluate it. > > Yes a cohesive approach would be ideal, but I do not know if pushing > substantially the same checks we have in the Crypto API down to > lib/crypto is the right way to go, I am not oppose but I guess Herbert > would have to chime in here. > -- Simo Sorce RHEL Crypto Team Red Hat, Inc
