On Mon, Nov 22, 2021 at 10:10 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Mon, 2021-11-22 at 07:55 +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 22, 2021 at 07:42:02AM +0100, Stephan Mueller wrote: > > > ... > > > I will leave the representatives from the distros to chime in and point to > > > these patches. > > > > Then why not work with the distros to get these changes merged into the > > kernel tree? They know that keeping things out-of-the-tree costs them > > time and money, so why are they keeping them there? > > I can speak for my distro. > We have not proposed them because they are hacks, we know they are > hacks, and we know they are not the long term solution. > Yet we have no better way (in our products, today) so far to deal with > these issues because what is needed is an effort like LRNG (does not > have to be this specific implementation), because hacks will not cut it > in the long term. Kernel support for FIPS validated crypto would be very useful, IMHO. Currently most folks I know and consult with use CentOS because CentOS is free and includes the FIPS canister for OpenSSL. Several folks I know and consult with don't have a solution because they use Debian derivatives, like Ubuntu. They use Ubuntu because Ubuntu offers the image processing packages they need out of the box. Moving the validated crypto into the kernel would be useful since all distros can provide it without the need for one-off patches. What I am less clear about.... NIST is only one standard body, and not everyone trusts the US. There are other bodies that should probably be represented, like KISA. So the big question becomes, how does the kernel offer "approved" crypto for different consumers? (where "approved" means blessed by some agency like NIST or KISA). Jeff
